Cream of the Crop 22/Cream of the Crop 22.iso/bbs/fnewsd45.zip/FIDO1345.NWS

Text File | 1996-11-04 | 165KB | 3,488 lines

     F I D O N E W S --       Volume 13, Number 45          4 November 1996
     +----------------------------+-----------------------------------------+
     |  The newsletter of the     |   ISSN 1198-4589 Published by:          |
     |    FidoNet community       |   "FidoNews"                            |
     |          _                 |        1-904-409-7040    [1:1/23]       |
     |         /  \               |                                         |
     |        /|oo \              |                                         |
     |       (_|  /_)             |                                         |
     |        _`@/_ \    _        |                                         |
     |       |     | \   \\       |   Editor:                               |
     |       | (*) |  \   ))      |        Christopher Baker  1:18/14       |
     |       |__U__| /  \//       |                                         |
     |        _//|| _\   /        |                                         |
     |       (_/(_|(____/         |                                         |
     |             (jm)           |     Newspapers should have no friends.  |
     |                            |                    -- JOSEPH PULITZER   |
     +----------------------------+-----------------------------------------+
     |               Submission address: FidoNews Editor 1:1/23             |
     +----------------------------------------------------------------------+
     |  MORE addresses:                                                     |
     |                                                                      |
     |    submissions=> [e-mail]                                |
     +----------------------------------------------------------------------+
     |    For  information,   copyrights,   article   submissions,          |
     |    obtaining copies of FidoNews or the internet gateway FAQ          |
     |    please refer to the end of this file.                             |
     +----------------------------------------------------------------------+


            HEADLINE CONTEST! SEND YOUR ENTRIES NOW!


                        Table of Contents
     1. EDITORIAL  ................................................  1
        A long Issue but a good start  ............................  1
     2. ARTICLES  .................................................  2
        A Short *.MSG Programming Tutorial [III]  .................  2
        Read Read Read  ...........................................  8
        The FTSC Charter?  ........................................ 11
        FTSC Comments  ............................................ 13
        Trias Politica and FidoNet  ............................... 14
        Are we talking about the same net?  ....................... 16
     3. COLUMNS  .................................................. 18
        Fidonet in Europe  ........................................ 18
     4. GETTING TECHNICAL  ........................................ 19
        FTS/FSC Master List  ...................................... 19
        FTS-0001 - The Basic FidoNet Standard for Operation  ...... 21
     5. COORDINATORS CORNER  ...................................... 48
        Nodelist-statistics as seen from Zone-2 for day 306  ...... 48
     6. NET HUMOR  ................................................ 49
        Who are Computer people?  ................................. 49
     7. NOTICES  .................................................. 51
        Future History  ........................................... 51
     8. FIDONET SOFTWARE LISTING  ................................. 52
        Latest Greatest Software Versions  ........................ 52
     9. FIDONEWS PUBLIC-KEY  ...................................... 59
        This Space intentionally left blank?  ..................... 59
     And more!
     FIDONEWS 13-45               Page 1                    4 Nov 1996


     =================================================================
                                 EDITORIAL
     =================================================================


     This Issue is long as I begin to publish the FTSC files on a weekly
     basis. The first one is FTS-0001 which specifies all the basic
     parameters for a FidoNet mail and file exchange session along with the
     message packet structure.

     In converting the original 80 column document to MAKENEWS' 70 column
     limit, the large tables became scrambled. They can be unscrambled if
     you send that section to an 80 column file or simpler yet, freq the
     original from here or from the source.

     Also included in this first effort is a complete list of all the FTS
     and FSC docs extant to my knowledge. All of the ones not marked
     *Obsolete* are available from the sources listed in the Masthead for
     FidoNews as well as here or from the FTSC Chairman's system at
     3:632/348 in Australia.

     Please consider FTS-0001 as this week's FidoNet History entry, too.

     A complete archive containing every doc listed further down is
     available here by the magicname of: FTSC or FTSC-ALL. Individual files
     are available here as listed. At the source [in Zone 3], the files may
     have alphanumeric designations so you might want to use an * for the
     file extensions if freqing from 'down under'.

     C.B.

     -----------------------------------------------------------------

     FIDONEWS 13-45               Page 2                    4 Nov 1996


     =================================================================
                                 ARTICLES
     =================================================================


     A Short *.MSG Programming Tutorial [III]
     Damian Walker, 2:2502/666

     In this last article of the *.MSG programming series I'll introduce
     some important issues about writing message files, and I'll also
     include the full source code for the message list program discussed in
     the previous two articles.

     Writing *.MSG Files

     Somewhere in FTS-1 it is mentioned that life is not a one-way street.
     Perhaps this is an odd observation to be found in a technical
     specification document, but it did provide me with a timely reminder
     that this tutorial should include something on writing messages as
     well as reading them.
         Most of the processes involved in writing a message should be
     reasonably obvious, being the opposite of reading.  Instead of reading
     a message and extracting addressing information and text, you build up
     the header and the text before writing to a file.  There are some
     extra considerations to be taken into account, however.
         The first is that of message numbering-- there must be some way to
     find out what number a new message should bear.  This is not an issue
     when rewriting an old message (to change its attributes, for
     instance), but it is essential that new messages should not overwrite
     existing ones, and it can be reasonably important in certain
     applications that the message is numerically the highest.  The
     following simple section of code can find out the next available
     message number:

         long findnextavail(char *filename, char *directory)
         {
             long nextavail,
                  current;
             struct ffblk f;
             int done;
             char wildcard[128];

             nextavail = 1;
             sprintf(wildcard, "%s*.msg", directory);
             done = findfirst(wildcard, &f, FA_ARCH);
             while(!done)
             {
                 current = atol(f.ff_name);
                 if(current >= nextavail)
                     nextavail = current + 1;
                 done = findnext(&f);
             }

             sprintf(filename, "%s%ld.MSG", directory, nextavail);
             return nextavail;
         }
     FIDONEWS 13-45               Page 3                    4 Nov 1996


     When the while loop is finished, 'nextavail' will contain the next
     available message number, which be returned to the calling process.
     I've also chosen to return the message number as a full *.MSG path and
     filename since this is more consistent with the examples used so far;
     a more elegant function would do one or the other.
         It is not always advisable to include this code in a generic write
     routine, since such a routine may also be needed to rewrite existing
     messages.  This is why I've included it in a separate function
     findnextavail(), which will return the information to a calling
     process which can then go on to pass the message number to the generic
     write routine.
         Values must be placed in the message header fields, and kludges
     must be prepared for extended addressing information, before the
     message is actually written out.  This information is more often than
     not prepared before the next available message number is sought.
         Not all fields need to be filled with meaningful data; some should
     preferably be used properly but are a little too advanced for this
     tutorial.  For example:

         timesread       int/2       Times read

     Can often be zeroed.  Also,

         cost            int/2       Cost word

     could be zeroed unless you wish to include message accounting in your
     program.  And then consider:

         destzone        int/2       Recipient's zone number
         origzone        int/2       Sender's zone number
         destpoint       int/2       Recipient's point number
         origpoint       int/2       Sender's point number

     Since these fields are not reliable, they are not actually used by
     software when reading messages.  Personally I fill them anyway, as a
     generic message write routine can take values placed in here to form
     the kludges which are actually used for the purpose of 4D addressing.

         replyto         int/2       Reply linking information

     This field can often be zeroed or ignored, as can:

         nextreply       int/2       Next reply to this message

     since they appear to be useful only in echomail, and most people store
     echomail in more advanced message bases than a *.MSG directory.
         All the other fields are mandatory, and the way they are filled
     really is application dependent, just as the way they are used after
     reading is also application dependent.  The difference is that few of
     the fields can be ignored when writing; you have to at least zero most
     of the fields mentioned above so that their contents are not mistaken
     for real values.
         As a simple example, let's imagine that I want to create an
     automatic robot message such as the following:

         ================================================================
     FIDONEWS 13-45               Page 4                    4 Nov 1996


         By: Automatic Robot, 2:2502/666.3
         To: Damian Walker, 2:2502/666.0
         Re: Netmail reminder
         St: Pvt Local
         ----------------------------------------------------------------
         This is your netmail reminder
         ================================================================

     This message could be typical of one generated by a netmail reminder
     program or appointments calendar, an idea I had for my newly found
     netmail programming skills, which I never took up.  Rather than use
     such a program as context for C code, I'll cheat and generate the
     message directly in the following program excerpt:

         #include <stdio.h>
         #include <time.h>
         #include "fidomsg.h"

         #define MAXMSGSIZE 2048

         void main(void)
         {
             struct fts1 msg;
             char text[MAXMSGSIZE];

             strcpy(msg.fromusername, "Automatic Robot");
             msg.origzone = 2;
             msg.orignet = 2502;
             msg.orignode = 666;
             msg.origpoint = 3;
             strcpy(msg.tousername, "Damian Walker");
             msg.destzone = 2;
             msg.destnet = 2502;
             msg.destnode = 666;
             msg.destpoint = 0;
             strcpy(msg.subject, "Netmail reminder");
             msg.attribute = MSGPVT | MSGLOCAL;
             strcpy(text, "This is your netmail reminder\r");
             msg.timesread = 0;
             msg.cost = 0;
             msg.replyto = 0;
             msg.nextreply = 0;

             /* post message */
         }

     In this example I have filled in the zone and point fields, in order
     that the generic post routine can pick these up and use them to
     generate the INTL, FMPT and TOPT kludges.  Notice also the fact that
     I've zeroed four of the fields I'm not really interested in.  I've
     left the date/timestamp generating code for the generic write
     function, although you can see that I've included the <time.h> header
     in readiness.  So let's see what such a generic write function would
     look like:

         int writemsg(struct fts1 *msg, char *text, char *filename)
     FIDONEWS 13-45               Page 5                    4 Nov 1996


         {
             FILE *msgfile;  /* message file handle info */
             int successful = 0;
             time_t timer;

             msgfile = fopen(filename, "wb");
             if(msgfile != NULL)
             {
                 time(&timer);
                 strftime(msg.datetime, 20, "%d %b %y  %H:%M:%S",
                     localtime(&timer));
                 fwrite(msg, sizeof(struct fts1), 1, msgfile);
                 if(msg.origzone != msg.destzone)
                     fprintf(msgfile, "\01INTL %d:%d/%d %d:%d/%d\r",
                         msg.destzone, msg.destnet, msg.destnode,
                         msg.origzone, msg.orignet, msg.orignode);
                 if(msg.origpoint != 0)
                     fprintf(msgfile, "\01FMPT %d\r", msg.origpoint);
                 if(msg.destpoint != 0)
                     fprintf(msgfile, "\01TOPT %d\r", msg.destpoint);
                 fprintf("%s\0", text);
                 fclose(msgfile);
                 successful = 1;
             }

             return successful;
         }

     Notice the order of operation.  First the message file is opened.  If
     the open is successful, the timestamp is generated in standard Fidonet
     date/time format as described earlier, before the header file is
     written.  Then the INTL kludge is written if the origin and
     destination zones differ.  Then the FMPT and TOPT are written as
     required.  Finally, the rest of the message text is added before the
     file is closed.
         This code does not include the MSGID kludge which netmail messages
     so often have now.  The MSGID kludge is in the form:

         ^AMSGID: zone:net/node.point xxxxxxxx

     where the xxxxxxxx is a 32-bit number.  Generation of this number is
     left to the implementation, but it must be as unique as possible.
     Some programs generate a completely random MSGID, but this runs the
     risk of identical MSGID's on two messages.
         When restricting your programming to netmail this isn't too much
     of a problem, since MSGID's are primarily intended for dupe checking
     and there is no dupe checking in netmail.  However, you may wish to
     experiment with more advanced algorithms for ensuring unique message
     identifiers, perhaps including the timestamp as a factor in the
     calculation.

     Final Message Lister

     The code in this tutorial has been pieced together, but never shown in
     its final form.  For convenience, I've included the full final message
     lister below.  I've taken the liberty of adding a few more comments to
     FIDONEWS 13-45               Page 6                    4 Nov 1996


     this listing, in order to make the complete program more easy to
     follow.

     ======================================================================
     FIDOMSG.H
     ----------------------------------------------------------------------
         /* FTS-1 message structure */
         struct fts1 {
             char    fromusername[36],
                     tousername[36],
                     subject[72],
                     datetime[20];
             int     timesread,
                     destnode,
                     orignode,
                     cost,
                     orignet,
                     destnet,
                     destzone,
                     origzone,
                     destpoint,
                     origpoint,
                     replyto,
                     attribute,
                     nextreply;
         };

         #define MSGPVT      0x0001    /* Private */
         #define MSGCRASH    0x0002    /* Crash message */
         #define MSGRECD     0x0004    /* Message received */
         #define MSGSENT     0x0008    /* Message sent */
         #define MSGFILE     0x0010    /* File attached */
         #define MSGTRANSIT  0x0020    /* In transit */
         #define MSGORPHAN   0x0040    /* Orphan */
         #define MSGKILL     0x0080    /* Kill/sent */
         #define MSGLOCAL    0x0100    /* Local */
         #define MSGHOLD     0x0200    /* Hold for pickup */
         #define MSGFREQ     0x0800    /* File request */
         #define MSGRRR      0x1000    /* Return receipt request */
         #define MSGIRR      0x2000    /* Is return receipt */
         #define MSGAUDIT    0x4000    /* Audit request */
         #define MSGUPDATE   0x8000    /* File update request */
     ======================================================================
     MSGLIST.C
     ----------------------------------------------------------------------
         #include <stdio.h>
         #include <dir.h>
         #include <string.h>
         #include <stdlib.h>
         #include "fidomsg.h"

         #define MAXMSGSIZE 2048
         #define MYZONE 2

         int readmsg(struct fts1 *msg, char *text, int limit,
             char *filename)
     FIDONEWS 13-45               Page 7                    4 Nov 1996


         {
             FILE *msgfile;  /* message file handle info */
             int successful = 0;
             char *kludgefind;
             int textlen;

             /* read and process message */
             msgfile = fopen(filename, "rb");
             if(msgfile != NULL)
             {
                 /* read header and text */
                 fread(msg, sizeof(struct fts1), 1, msgfile);
                 textlen = fread(text, 1, limit, msgfile);
                 if(textlen < limit)
                     text[textlen] = '\0';
                 else
                     text[limit - 1] = '\0';
                 fclose(msgfile);
                 successful = 1;

                 /* identify zone information */
                 kludgefind = strstr(text, "\01INTL");
                 if(kludgefind == NULL)
                 {
                     msg->origzone = MYZONE;
                     msg->destzone = MYZONE;
                 }
                 else
                 {
                     kludgefind = strchr(kludgefind, ' ');
                     msg->destzone = atoi(kludgefind);
                     kludgefind = strchr(&kludgefind[1], ' ');
                     msg->origzone = atoi(kludgefind);
                 }

                 /* identify point information */
                 kludgefind = strstr(text, "\01FMPT");
                 if(kludgefind == NULL)
                     msg->origpoint = 0;
                 else
                     msg->origpoint = atoi( &kludgefind[6] );
                 kludgefind = strstr(text, "\01TOPT");
                 if(kludgefind == NULL)
                     msg->destpoint = 0;
                 else
                     msg->destpoint = atoi( &kludgefind[6] );
             }

             return successful;
         }

         void main(void)
         {
             struct fts1 msg;
             struct ffblk f;
             char text[MAXMSGSIZE], directory[128], wildcard[128],
     FIDONEWS 13-45               Page 8                    4 Nov 1996


                  msgname[128];
             int done;

             /* initialise directory and wilcard */
             strcpy(directory, "\\fd\\mail\\");
             sprintf(wildcard, "%s*.msg", directory);

             /* main list output section */
             done = findfirst(wildcard, &f, FA_ARCH);
             while(!done)
             {
                 sprintf(msgname, "%s%s", directory, f.ff_name);
                 readmsg(&msg, text, MAXMSGSIZE, msgname);
                 printf("%-12s From: %s (%d:%d/%d.%d)\n", f.ff_name,
                     msg.fromusername, msg.origzone, msg.orignet,
                     msg.orignode, msg.origpoint);
                 done = findnext(&f);
             }
         }
     ======================================================================

     Conclusion

     Although there is much more to know about *.MSG netmail messages than
     is covered in this brief tutorial, I hope that it has given a start to
     those of you who were interested in message programming.
         If you're a programmer who uses a language other than C, but you
     can read C code, then the concepts discussed here can be easily
     transferred.  I've successfully written message routines in both C and
     BASIC using the same principles.
         And now a few acknowledgements.  Thanks must go to Bill Birrell at
     2:2504/200, as he originally showed in the C_ECHO how simple the
     rudimentary message programming could be, and thus got me started
     along the road to writing a successful piece of Fidonet software.
         Information about *.MSG files was drawn from FTS-1 and from my own
     code.  Most of the code was written specially for this tutorial, with
     the exception of a small section of the header file extracted from
     the InfoMail source code.
         Some general information on the C language and its functions as
     used here was obtained from K&R's 'The C Programming Language' (second
     edition) and from the 'info' documentation for the DJGPP compiler.
         As with all articles submitted by me for FidoNews, feedback is
     always welcome.

     -----------------------------------------------------------------


     Read Read Read
        by Bob Moravsik

     I'll limit this article to addressing only three
     issues:

     1.  The foolish attempt at a local policy in Z2
     2.  Our nodelist policeman
     3.  The Elist and R13 conference.
     FIDONEWS 13-45               Page 9                    4 Nov 1996


     Mr. Kindness of Z2 dismisses section one of policy 4.07
     by the old...its none of your business.  Probably the
     only rebutable he has left in his diminishing arsenal.
     An "echopol" in Z2, because it might only apply to Z2
     is a "local policy".  Section one of Fidonet's policy
     (a brilliant piece of work) addresses this:

     "Seperate policy documents may be issued at the zone,
     region or net level to provide ADDITIONAL detail on
     local procedures."  let's stop here for a minute.

       This policy may only profide ADDITIONAL details
       not different ones and the must address local
       PROCEDURES.  Very limiting...let's go on

     "Ordinarily, these local level policies may not
     contradict this policy.  However (the exception), with
     the APROVAL OF THE INTERNATIONAL COORDINATATOR (note)
     local policy can be used to implement differences REQUIRED
     due to local conditions."  OK  let's pause.

     Can't contradict, but they may if:

         1. Approved by the IC
         2. and differences are REQUIRED...

     Again...pretty limitting.

     "These local policies MAY NOT place additional restrictions
     on members of Fidonet beyond those included in this document
     OTHER then enforcement of local periods."

        1. No additional restrictions.

     Simply taken all together:

     Z2 Woodmorepol:

        1. Limited to ADDITIONAL details
        2. Must be approved by the IC if there are differences.
        3. These difference must be REQUIRED (not desired)
        4. They can interpose ADDITIONAL restrictions.

     Section one was designed to prevent a local policy for
     the sake of itself.  Mr. Kindness indicates that a
     Zone 2 policy would only apply to Z2 conferences.
     What's a Z2 conference ?  Originates in Z2 ?  Travels
     only in Z2 ?  Has only a Z2 moderator. ?  See the
     foolishness.  A Z2 router routes FN_SYSOP and Z2_SYSOP.
     Does Woodmorepol apply to one and not the other ?

     In summary...a geographic policy is impractical in
     an internation society.  It serves NO PURPOSE.  It
     does nothing good except serve as a "prayer" to the
     local Fidogods.

     FIDONEWS 13-45               Page 10                   4 Nov 1996


     Mr. Kindness, I do applaud you recognition of a global
     policy HOWEVER...Fidonet has 6 zones.  Any replacement
     policy which includes echomail or conferences requires
     50%+1 of the RC's to present to the IC THEN 50%+1 of
     the *C's to vote for it positively.   Until then all
     you have is a "circle jerk" which any node in Z2 can
     "attack" as being violative of section one.  Section 8
     does not provide for a local ratification of Woodmorepol.
     You have to use wild imagination to read THAT into 9.9.

     Lastly...it IS my business and I will continue to
     make it my business.  By not filing a PC against me
     it is your admission that I'm right and you are wrong.
     My  NC is Sean Aldrich 1:2606/0...the lines are open.

     ++++The Nodelist police

     I see an article which is a netmail from John Souvestre aka
     John John where he is doing ZC1 impressions.  I looked
     through policy to see where they define a John John.  Not
     there (at least I'm an HC).  In the Fidonet conference John
     John was as who made HIM the spokesperson for the ZC1.  The
     reply was a "sidestep" with a not ma job retort.  Is John
     John looking for the IC slot ?  Remember, John John runs
     a business selling echomail links via internet for $30
     a month.  Is there a connection ?  Is Fidonet going
     "commercial".   What's the motivation for John John to
     strap on a cap gun, get the plastic badge from a cerial
     box and point the guns at the ZC2.  Seems to me Bob Satti
     should be resolving this issue IF IN FACT IT REALLY EXISTS.
     The absense of the ZC1's statement on the Z2 segment is
     indicative of an issue made up for a purpose OTHER then
     Fidonet.   But then its hard to discuss much with John
     John.  He filters out anybody that doesn't agree with him.

     +++++Region 13's echos and the Elist.

     Region 13 has lots of region echos now.  None anymore
     official then the rest.    The RC's conference is limited
     to his friends and the rest of the region uses the
     original ones.  Region 13 is composed of two practical
     regions.  The one the RC coordinates with  5/6 nets
     and the rest which is "self coordinaed".  The nodes have
     the choice as to the conferences.   Its what Fidonet is
     all about.  The free and unrestricted right to communicate
     subject only to the restrictions in Policy 4.07.

     To conclude this matter.  The RC 13 became guided more
     by an emotional outburst then his obligation to provide
     for smooth operations.  After sending threating EMAIL and
     now seeing that he was 100% in the wrong chooses to
     remain unavailable to most of the region and will
     bide his time until replaced.  Pretty PATHETIC.

     Bob Moravsik

     FIDONEWS 13-45               Page 11                   4 Nov 1996


     -----------------------------------------------------------------


     Furry, Tender, Sad Creatures
     by Lee Kindness, 2:259/7, [e-mail]

     When i asked about the FTSC 'charter' in NET_DEV i received this via
     crash mail. It makes quite interesting reading, especially points B1
     and B3c, which have not been met by the FTSC.

     It is also worth noting that FSC-0000 (or FTS-0000) no longer exists
     in the FTSC archive.

     Oh, just for the hell of it, I've highlighted the three spelling
     mistakes in the FTSC's document - Spelling ain't their strong
     point ;)

                          FidoNet(tm) Standards Committee
                              FSC Goals and Organization
                              FSC000-6 - August 18, 1986


      A. The Problems

         1. Implementors of FidoNet software (Fido itself and the many
            emerging 'FidoClones') need a rigorous definition of FidoNet.

         2. When deciding whether to list a class of nodes in the node
            list, the IFNA has no way of knowing if a FidoClone is
            sufficiently compatible with FidoNet to be 'safe' to list.

         3. Sysops need to know if a particular system will allow them to
            access FidoNet.

         4. There are already two significant FidoNet standards, the one
            that is implemented by Fido, and SEAdog's extensions; plus at
            least one clone that seems incompatible (not by intent).  The
            situation is becoming urgent.


      B. The Goals

         1. Provide to implementors a rigorous definition of FidoNet and
            all FidoNet protocols sufficient to implement a FidoClone
            without recourse to other sources.

         2. Provide to IFNA the means to determine whether a system is
            compatible with FidoNet.  This will allow the IFNA to list
            compatible systems so Sysops may decide which system to
            install.

         3. Produce the standards in three stages:

            a) Immediately document the existing FidoNet as implemented by
               Fido itself,

     FIDONEWS 13-45               Page 12                   4 Nov 1996


            b) Expand the definition to include SEAdog's capabilities, and

            c) Produce a newer, better, prettier, ... standard which
               incorporates all the wonderful ideas we hear while defining
               the first two above.

      C. What is to be Standardized
         1. The Data Transmitted
         2. The Connection
         3. The Protocols
         4. The Node List
         5. Routing

      D. The Products

         1. Base FidoNet Definition - FidoNet as implemented by Fido
            See document FSC001

         2. Standard for FidoNet with SEAdog and Other Existing Extensions
            This is a similar to the Fido version above, but provides a
            place to note the extensions and structural differences
            a) Extensions
               o File Request
               o Update Request
               o Return Receipt Request
               o Audit trail request
               o Passwording Pickup
               o Always do CRC
            b) Deletions

         3. Extended FidoNet Definition
            Suggestions and ideas without regard to merit.  Inclusion
            implies absoloutely no commitment to standardization.
                    ^^^^^^^^^^^ [absolutely]
            a) Extensions
               1) Expanded net hierarchy (TH)
               2) Make connection like logon so mono-modal implementations
                  can be done (JB)
               3) Add who REALLY from/to packet (TH)
               4) Room for product-specific info in packet (TH)
               5) Security (GW)
                  a> Sending passwords (validating GETs and PICKUPs)
                  b> Message encryption.  When on an intermediate node,
                     origin and final destination may be confidential.
               6) Non-homogenous messages in packet using MSGX2 (GW)
                      ^^^^^^^^^^ [homogeneous]
            b) Deletions

         4. NodeList and NodeList Processing
            See document FSC002

      E. Members
         1. Ben Baker 100/76, IFNA Technical
         2. Randy Bush 122/6, Documentation
         3. Bob Hartman 132/101, Protocol Review
         4. Thom Henderson 107/8, SEAdog
     FIDONEWS 13-45               Page 13                   4 Nov 1996


         5. Tom Jennings 125/1, Fido
         6. Ken Kaplan 100/22, IFNA Admin
         7. Gee Wong 107/312, Testing and Validation


      F. Acknowledgements
         ^^^^^^^^^^^^^^^^ [Acknowledgments]

         FidoNet is a trademark of Tom Jennings

     -----------------------------------------------------------------


     FTSC Comments, observations and general lilac wallpaper
     by Lee Kindness, 2:259/7, [e-mail],
     http://www.scms.rgu.ac.uk/students/cs_yr94/lk/fido.html

     Editorial of fnewsd43:
      > The FTSC does NOT create standards nor does it impose standards.
      > The FTSC documents existing standards as they become de facto
      > operational practices for the majority of FidoNet participants
      > and/or software

     That quote and various other messages by Heller in NET_DEV lead to
     the interpretation that even thou the FTSC has not published or
     promoted FTS documents in the recent past (OK there was a FTS-0005
     UPDATE) this is because the current FTS documents represent the
     present standards in use in Fidonet... hmmm...

     I invite all the FTSC to have a quick look in some packets on their
     (well here we're assuming there Fidonet members) systems. Chances
     are you'll find a type 2+ or 2.2 packet there and not an FTS-0001
     type 2 packet. So does FTS-0001 reflect common practise? There's more
     to be picked at in FTS-0001 too. But you know what the worst thing is?
     FTS-0001 is a document that is copyrighted by a person THAT NO LONGER
     IS A FIDONET MEMBER, we cannot update it without his consent (along
     with a number of other FTS documents)

     The FTSC should never have accepted copyright documents into its
     archive!

     And now lets take a look at FTS-0004... Oh this one is a real treat!

      o It's just an extract from a programs documentation! (Published by
        a FTSC that will not promote the IEMSI spec to FTS status due to
        its format)

      o Tear line:

        o Do we need it?

        o What's the maximum size?

      o Origin line, that is nice! FTS-004 states:

        o It is optional (ha, send a message and see how far it gets,
     FIDONEWS 13-45               Page 14                   4 Nov 1996


          or what the recipient thinks your address is)

        o Although it shows an example with the network address in
          brackets, it does not state these are required.

        o No maximum size.

      o SEEN-BY lines:

        o No maximum line length

        o No maximum amount of lines (even thou the Conference Mail
          System itself strips lines after a certain amount).

        o Does not state SEEN-BY lines must be stripped at zone gates
          (due to their 2D nature).

        o Does not state net/node pairs must be in sorted order, with a
          sticky net.

      o PATH lines:

        o States no maximum line length.

        o No maximum amount of lines.

        o States the PATH line is OPTIONAL!!!

        o Does not state net/node pairs must be in sorted order, with a
          sticky net.

     FSC-0074 should have been adopted as FTS-0004 the minute it was
     submitted to the FTSC! (well before the FTSC put the stupid ^A should
     be handled equally rubbish). When Chris said he'll be posting the FTS
     documents in future issues of Fidonews I was sitting there saying

      "Yeh, FTS-0004 will have an extension of .JOK"

     The structure and membership of the FTSC is also amazing. Long gone
     are the days of the FTSC echo, the FTSC now communicates using an
     internet e-mail list... Long gone are the days of the FTSC file echo
     to transport updated/new documents to fidonet nodes, got to get them
     by the internet now... Actually I'd be willing to bet that at least
     half of the FTSCs members don't even use Fidonet!

     I'm sure that's a couple of points for the FTSC to mull over...

     -----------------------------------------------------------------


     Trias Politica and FidoNet
     By Frederik Retsema (2:280/905.1)

     ------------------------------------------------------------------
     - Readers in Holland: this article is an English translation of  -
     - the Cursief-part in R28-nieuws of October 1996. You might want -
     FIDONEWS 13-45               Page 15                   4 Nov 1996


     - to read the Dutch article and react in the Dutch echomailarea  -
     - CSO.028.                                                       -
     -                                                                -
     - Readers in zone 2: this article is also posted in the area     -
     - ECHOPOL2. You might want to react there.                       -
     ------------------------------------------------------------------

     In zone 2 we are trying to make a new Echomail-policy. One of the
     main problems seems to be the "powerplay" of some moderators. I
     think one of the basics of the "real-world", the so-called Trias
     Politica may help to solve this problem.

     At school (an IT-school with much Economic stuff) I learned about
     this Trias Politica. It means that the way we deal with rules is
     split up in three parts:

     1 people who make rules (normally: the Government)
     2 people who take care that others obey the rules (normally: the
       police)
     3 people who judge about people who don't agree with each other
       about the rules (on a case-by-case base).

     Each of these parts is independent of each other: judges f.e. don't
     make rules, politicians don't judge in specific cases (but: are
     allowed to change rules to prevent judges to judge in the same way
     again). Someone can have a role in one of these parts, but never
     in more then one.

     This prevents powerplay: judges are independent, but have to stick
     to the rules, police must stick to the rules, but if a judge dis-
     agrees with the way the rules are dealt with he can overrule the
     decision of the police. The Government can play powerplay with the
     rules, but well, there has to be a great majority of people who
     agrees with these rules to implement these rules. The less contro-
     versial the rule, the more change to be implemented.

     Now let's have a look at FidoNet.

     Moderators are allowed to make the rules (part 1), are allowed to
     judge about these rules (part 3) and are allowed to act against
     people who don't obey these rules (part 2). See the problem ? This
     is _the_ base of powerplay.

     Let's go one step higher: the *EC's. These people are allowed to
     deal with problems between moderators and echo-participants
     (part 3), are allowed to take actions against people generating
     dupes (part 2) and in zone 2 the ZEC has also a key-role in making
     the rules for echomail (part 1).

     FidoNet has separated the tasks of netmail- and echomail-
     coordinators by making *C's and *EC's, has also separated the task
     at regional levels (area, net, region and zone), but at each level
     each coordinator has ALL types of powers.

     I think it would be wise to change this. An example of how this
     could be done:
     FIDONEWS 13-45               Page 16                   4 Nov 1996


     Area-level:
     -----------
     Moderators: I think anyone agrees that the key-role of a moderator
     is to enforce the echorules. So let him ONLY enforce the rules: if
     someone doesn't stick to the rules, let the moderator warn him and
     let him cut links if he thinks links should be cut.

     Echomail-keeper: to make it possible for *EC's to see what has
     happened IN the area an independent echomail-keeper should keep at
     least (let's say) three months of echomail of that area. This task
     should NOT be done by the moderator, as the moderator is likely to
     be one of the party's in the judgement of the *EC (and therefore
     the moderator might gain profit by deleting some messages).

     Rule-changes: When someone wants the rules to change, then he may
     make a proposal of better rules. This new rules-file can then be
     subject to a vote. When more than 50% of the people who voted
     agrees that the new proposal is a good one, this new rules-file
     will act as the new echomail-rules. The moderator should NOT be
     the returning officer of the vote, as the moderator would have two
     different parts of the Trias Politica.

     Net/Region/Zone-level
     ---------------------
     *EC's: let these people ONLY judge. Not dealing in making policy's
     (this can as well be a dedicated task, performed by a skilled node
     or point), not enforcing rules at dupes, etc.

     CRP-organisations: Cost Recovery Program-organisations (in Holland
     also called CSO's: Cost Sharing Organisations) do deal already with
     links: let these organisations also deal with the dupes. Problems
     with dupes can be dealt with by people or workgroups within these
     CRP's, just as people in these CRP's please. When more than one CRP
     is active for one area, let the CRP's coordinate the links between
     the CRP's and let the *EC-structure judge when two CRP's disagree.

     Rule-changes: see area-level. Let ANYONE who thinks some rules can
     be improved say so in the international areas or in FidoNews, let's
     think about it, discuss it and let's vote about it. It is not
     recommended to let a *EC to be the returning-officer.

     A reaction to these ideas would be appreciated ;-).

     Frederik Retsema
     (2:280/905.1)

     -----------------------------------------------------------------


     Are We Talking About the Same UN'I-Net?
     Seanette Blaylock, 1:206/2735, [e-mail]

     This is in response to a Fidonews article submitted by Rob A Shinn
     ([e-mail]).

     Mr. Shinn, in citing examples of networks with overly restrictive
     FIDONEWS 13-45               Page 17                   4 Nov 1996


     rules, cites UN'I-Net as being so restrictive that a user can be
     kicked off the net for misspelling the net's name.

     With no disrespect to Mr. Shinn intended, I can't help wondering if
     he's thinking of the same UN'I-Net that I've been an active, regular
     participant in since about April 1994. In that time, I've seen a very
     few people given temporary "vacations" from specific conferences for
     behavior that in Fido terms would be deemed "excessively annoying"
     and was in direct violation of conference rules and/or what few net
     guidelines exist.

     My husband has been a regular, active participant on UN'I-Net for
     considerably longer than I have. In his time on the net, he recalls
     exactly *one* case of a user being kicked off the net, and this was
     for *repeated* posting of commercial advertisements in conferences
     in which this was a violation of conference rules. The offender,
     according to my information, deliberately continued these posts after
     receiving warnings from the hosts of the affected conferences.

     I've heard quite a bit of hearsay about Intelec, but have never
     participated in that network, so I won't comment on Mr. Shinn's
     remarks, except to say that his comments about Intelec match what
     I've heard from sources I consider reliable.

     I've greatly enjoyed my participation on UN'I-Net. It's not as varied
     or geographically wide-spread as Fido, but both nets have their good
     points, mostly the people who use them. I'm sorry Mr. Shinn apparently
     has a grudge against UN'I-Net, but his remarks about the net in
     question were completely at odds with my own experiences on that net.

     Respectfully submitted,
     Seanette Blaylock

     -----------------------------------------------------------------

     FIDONEWS 13-45               Page 18                   4 Nov 1996


     =================================================================
                                  COLUMNS
     =================================================================


     [This is the first of a promised series of weekly reports from
      Europe.] Ed.

     FIDONET IN EUROPE
     -----------------
     by Dave Meikle [2:259/58.90 , [e-mail]]

     No mail has been send to me but there is two things hapening in
     Scotland First:

                       <-> THE REBEL JAMBO BBS <->
                  Home Of The Fidonet in Europe Coloum
                         Fidonet: 2:259/58.90
                   [e-mail]

     We have produced a WWW page , it is at :
                http://www.thebbslist.com/free-page/rebeljambo.html

     Second:
                             The /\/ess BBS
            Fidonet: 2:259/57.7       Amiganet: 39:137/10.7
            Ufo/BBSnet: 405:126/2.7   eMAIL: [e-mail]

             [phone]     7days 10pm-7am Uk.

     Thats all this week Remember the Submission address's are

     FIDONET: Europe@2:259/58.90
     eMAIL: [e-mail]

     Cheers Dave

     -----------------------------------------------------------------

     FIDONEWS 13-45               Page 19                   4 Nov 1996


     =================================================================
                             GETTING TECHNICAL
     =================================================================


     [This is a list of all the Standards and Proposals recorded at the
     time of its publishing. These files are available at most of the
     sources listed in the Masthead info at the end of FidoNews. They are
     all available here at 1:18/14. An FTS is a Standard. Some are
     mandatory and some are not. If they are used, they must be used as
     published. An FSC is a proposal. If they are used, they should be used
     as published but such use cannot be mandated.] Ed.


     -   FidoNet Technical Standards Committee Document Archive
     -   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     -   Official FidoNet Technical Standards
     -
     FTS-0001.ZIP A basic FidoNet(r) technical standard, R Bush
     FTS-0002     *Obsoleted by FTS-0005*
     FTS-0003     *Obsoleted by FTS-0006*
     FTS-0004.ZIP Echomail specification, B Hartman
     FTS-0005.ZIP The distribution nodelist,  B Baker, R Moore
     FTS-0006.ZIP YOOHOO and YOOHOO/2U2, V Perriello
     FTS-0007.ZIP SEAlink protocol extension, P Becker
     FTS-0008.ZIP Bark file-request protocol extension, P Becker
     FTS-0009.ZIP Message identification and reply linkage, j nutt
     -
     -   FidoNet Standards Proposals And Miscellaneous Documents
     -   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     FSC-0001     *Obsoleted by FTS-0001*
     FSC-0002     *Obsoleted by FTS-0005*
     FSC-0003.ZIP FidoNet Route Files Explained, B Baker
     FSC-0004.ZIP Zones and Zonegates explained primitively, R Bush
     FSC-0005.ZIP Opus 1.01 Netmail passwording scheme, W Wagner
     FSC-0006     *Obsoleted by FTS-0006*
     FSC-0007.ZIP RFC-822-style msg header proposal, R Heller
     FSC-0008.lzh *Obsoleted by FSC-0015
     FSC-0009.ZIP Nodelist Flag Draft Document Gwinn/Dodell
     FSC-0010.ZIP Dutchie 2.80 SEAlink File Resynch, H Wevers
     FSC-0011.ZIP Experiences/corrections to FSC-0001, B Hartman
     FSC-0012     *Obsoleted by FTS-0004*
     FSC-0013     *Obsoleted by FTS-0008*
     FSC-0014.ZIP Binary-style msg proposal, W Wagner
     FSC-0015.ZIP FOSSIL 5.0 Documentation, R Moore
     FSC-0016.ZIP FidoNet Mail Session Startup, R Hartman
     FSC-0017.ZIP Archive Philosophy and Document Naming, R Bush
     FSC-0018     *Obsoleted by FTS-LIST*
     FSC-0019     *Obsoleted by FTS-0007*
     FSC-0020.ZIP Alternate Nodelist Flag Proposal M Presnell
     FSC-0021.ZIP VFOSSIL, OS/2 Video FOSSIL Appendage R Moore
     FSC-0022     *Obsoleted by FSC-0090*
     FSC-0023.ZIP Bundle naming convention proposal R Meyer
     FSC-0024.ZIP Binary bundle proposal, O McDonald
     FSC-0025.ZIP AVATAR Video Spec, G Stanislav
     FSC-0026     *Obsoleted by FTS-LIST*
     FIDONEWS 13-45               Page 20                   4 Nov 1996


     FSC-0027     *Obsoleted by FTS-0005*
     FSC-0028.ZIP Proposed file-forwarding standard, H Lee
     FSC-0029     *Reserved for future use*
     FSC-0030.ZIP Proposal for message identification, J Cowan
     FSC-0031.ZIP Proposed message id/linkage standard, M Ratledge
     FSC-0032.ZIP Proposed message quoting standard, M Ratledge
     FSC-0033.ZIP Proposal for message identification, T Kover
     FSC-0034.ZIP Gateways to and from FidoNet, R Bush
     FSC-0035.ZIP Transparent gateways to/from FidoNet, M Shiels
     FSC-0036.ZIP Group Mail specification, D Lovell
     FSC-0037.ZIP AVATAR 0+ Video Spec, G Stanislav
     FSC-0038.ZIP Proposed domain gating protocol, j nutt
     FSC-0039.ZIP A type-2 packet extension proposal, M Howard
     FSC-0040.ZIP Proposed modem handling extension, M Shiels
     FSC-0041     *Obsoleted by FTS-0009*
     FSC-0042.ZIP A modified gateway agreement, S Furber
     FSC-0043.ZIP Some hints on recognizing control lines in FidoNet(r)
                  message text, R Bush
     FSC-0044.ZIP Improved duplicate detection, J Decker
     FSC-0045.ZIP Proposed new packet header, T Henderson
     FSC-0046.ZIP Proposed product identifier, J Homrighausen
     FSC-0047.ZIP The ^ASPLIT kludge line, P Terry
     FSC-0048.ZIP Proposed type-2 packet extension, J Vroonhof
     FSC-0049.ZIP A proposal for passing domain information during FTS-0006
                  sessions, B Hartman
     FSC-0050.ZIP A character set identifier for FidoNet message editors, T
                  Sundblom
     FSC-0051.ZIP A system-independent way of transferring special
                  characters,  T Gradin
     FSC-0052.ZIP A proposal for making the PATH zone aware, G van der Land
     FSC-0053.ZIP Specifications for the ^aFLAGS field, J Homrighausen
     FSC-0054.ZIP The CHARSET proposal,  D McNutt
     FSC-0054.ZIP A system independant way of transferring special
                  characters, Duncan McNutt
     FSC-0055.ZIP Security passwords in nodelist updates, L Kolin
     FSC-0056.ZIP EMSI/IEMSI Protocol Definition, J Homrighausen
     FSC-0057.ZIP Echo Area Managers - Specifications For Requests, F
                  Fabris, J Homrighausen
     FSC-0058.ZIP A New Way Of Addressing In FidoNet, W Van Sebroeck, J
                  Spooren
     FSC-0059.ZIP Newsgroup Interchange within FidoNet, J Decker
     FSC-0060.ZIP Calculation and Usage of CRC's, F van der Loos
     FSC-0061.ZIP Proposed Guidelines for the FileBone, E VanRiper
     FSC-0062.ZIP Nodelist Flag Indicating Online Times, D Thomas
     FSC-0063.ZIP Proposal For FidoNet Messages, J Miller
     FSC-0064.ZIP InterDomain Message ID, Gating, Linking and Addressing, J
                  Penner
     FSC-0065.ZIP Type 3 ASCII: A Proposal, M Kimes
     FSC-0066.ZIP Type 3 Binary: A Proposal, M Kimes
     FSC-0067.ZIP A Proposal For Sensible Kludge Lines, M Kimes
     FSC-0068.ZIP A Proposed Replacement For FTS-0004, M. Kimes
     FSC-0069.ZIP A FidoNet (FTN) Domain Name Service, R Heller F Arnaud
     FSC-0070.ZIP Improving FidoNet/UseNet Gating and Dupe Checking,
     FSC-0071.ZIP Distributed FREQ (DFREQ) Specifications, B Auclair
     FSC-0072.ZIP The HYDRA file transfer protocol, J Homrighausen, A Lentz
     FSC-0073.ZIP Encrypted message identification for FidoNet, John Mudge
     FIDONEWS 13-45               Page 21                   4 Nov 1996


     FSC-0074.ZIP Proposed echomail specification, J Souvestre, D Troendle,
                  B Davis, G Peace
     FSC-0075.ZIP Proposal for ISDN capability flags in the nodelist, J
                  Ceuleers
     FSC-0076.ZIP Proposal for netmail areatags, S Gove
     FSC-0077.ZIP Proposed type-10 packet format, J Steck
     FSC-0078.ZIP Gateway between FidoNet compatible networks, C Lacerda
     FSC-0079.ZIP RTF mail: proposal for message formatting in the type-2
                  message packet, K Axon
     FSC-0080.ZIP Describing FidoNet with a layered model, Mikael Staldal
     FSC-0081.ZIP A type-3 packet proposal, Mikael Staldal
     FSC-0082.ZIP A proposed new packet type, S. Slabihoud
     FSC-0083.ZIP A proposed standard for message IDs on FTN systems,
                  J.de.Boyne.Pollard
     FSC-0084.ZIP EDX1: Electronic Data Exchange standard level 1, D.Bider
     FSC-0085.ZIP Proposal for the "NOZIP" and "ERX" nodelist flags,
                  D.Bider
     FSC-0086.ZIP SRIF: Description of a new Standard Requestion
                  Information File, M.Mucko
     FSC-0087.ZIP File forwarding in FidoNet technology networks,
                  R.Williamson
     FSC-0088.ZIP Compatibility and Link Qualifier Extensions for EMSI
                  sessions, R.Williamson
     FSC-0089.ZIP The INTL: netmail addressing control line, R.Williamson
     FSC-0090.ZIP FTSC Product Codes and Application Form
     FSC-0091.ZIP Proposal for ISDN nodelist flags, A Lentz
     FSC-0092.ZIP New control lines for forwarded messages, M.Hohner
     FSC-0093.ZIP Reduced seen-by lines, F.Ellermann
     -
     - FTSC Administrative Files
     -
     FTSCLIST.ZIP Directory of all FTSC files
     FTSCPROD.ZIP FTSC Product Codes (see also FSC-0091)
     -
     FTSC-ALL.ZIP Archive of all FTSC files as above

      -30-

     -----------------------------------------------------------------


     [This FTS was reformatted to fit the 70 character limit. The large
     tables suffered in the conversion. These are for info only. File-
     request a real copy soon for a neater presentation.] Ed.

     Document: FTS-0001
     Version:  016
     Date:     30-Sep-95


                          A Basic FidoNet(r) Technical Standard
     |                                Revision 16
                           Formerly known as FSC001,  FSC-0001
     |                      Randy Bush, Pacific Systems Group
     |                             September 30, 1995

     FIDONEWS 13-45               Page 22                   4 Nov 1996


     Status of this document:

         This FTS  (FidoNet(r)  Technical  Standard)  specifies  a
         standard  for the FidoNet community. FidoNet nodes are expected to
         adopt and implement this standard. Distribution is subject to the
         restrictions stated in the copyright paragraph below.

         Fido and FidoNet are registered marks of Tom Jennings and Fido
         Software.

         Copyright  1986-95,  Randy  Bush.  All  rights  reserved.   A
         right  to distribute only  without modification  and only at no
         charge is granted.  Under no  circumstances is this document to be
         reproduced or distributed as  part of  or packaged with any
         product or other sales transaction for which any fee is charged.
         Any and all other reproduction  or excerpting requires the
         explicit written consent of the author.


      A. Introduction

         FidoNet  has  grown  beyond  most  peoples' fantasies, and  new
         FidoNet implementations  are appearing regularly.  Unfortunately,
         the  scattered nature of the documentation and absence of clear
         testing procedures have made  implementation  difficult.
         FidoNet, in its desire to promote and encourage  FidoNet
         implementations,  suggested  a project  to create a technical
         standard for  FidoNet.  The author did not  design or specify
         the data formats or protocols, only attempted to document them.

         This  document defines the  data structures and communication
         protocols which a FidoNet implementation must provide.  The
         implementor of FidoNet compatible systems is the intended audience
         of this document.

         The  layered metaphor of the ISO Open Systems Interface reference
         model has been used to view FidoNet from a standard perspective.
         As with most prospective  ISO/OSI  descriptions, FidoNet  does not
         always  make  this easy.

         The  content of this document  was gleaned from the references
         given  at the  end.

         Please direct technical comments and errata to
     |     Randy Bush                       [e-mail]
     |     Pacific Systems Group
           9501 S.W. Westhaven Drive
           Portland, Oregon  US-97225
     |

        1. Basic Requirements for a FidoNet Implementation

           Compatibility is a set of abilities which, when taken as a
           whole, make it safe to list a net or node in the FidoNet
           nodelist. In other words, if  another  node should attempt
           contact, does it have  a reasonable chance  of successful
     FIDONEWS 13-45               Page 23                   4 Nov 1996


           communication?  This is a social obligation,  as the  calling
           system  pays  money  for the  attempt.  Conversely,  an
           implementation  should be able to successfully contact other
           systems, as life is not a one-way street.

           A FidoNet implementation must be able to call other nodes and
           transfer messages and files in both directions.  This includes
           pickup and poll.  A FidoNet implementation must be able to
           accept calls from other nodes and  transfer  messages and  files
           in both directions.  This includes pickup.

           FidoNet implementations must be able to receive and process the
           FidoNet format  nodelist, and transfer nodelists to other nodes.
           A  companion document,  FTS-0005, defines the FidoNet format
           nodelist  and  how  to interpret and process it.

           A  FidoNet implementation must route messages which do not have
           files attached through net hosts as shown in a FidoNet format
           nodelist.


        2. Levels of Compliance

           This  documents represents the  most basic FidoNet
           implementation.   A future  document will define well tested
           extensions which are optional but  provide sufficient
           additional function that implementors should seriously
           consider   them.   SEAdog(tm),  from  System Enhancement
           Associates,  is  an  excellent  example  of such an extended
           FidoNet implementation.


        3. The ISO/OSI Reference Model (cribbed from "Protocol Verification
           via Executable Logic Specifications", D. P. Sidhu, in Rudin &
           West)

           In  the ISO/OSI model, a distributed system consists of entities
           that communicate  with  each other  according  to a set of rules
           called  a protocol.   The  model is  layered, and there are
           entities associated with  each layer of the model which provide
           services to higher  layers by  exchanging information with their
           peer entities using the services of  lower layers.  The only
           actual physical communication between  two systems is at the
           lowest level.

           Several  techniques  have  been  used  in the  specification  of
           such protocols.  A common ingredient in all techniques is the
           notion of the extended  finite  state automata  or machine.
           Extensions include  the addition of state variables for the
           storing of state information about the  protocol.  The state of
           an  automation can change as a result  of one of the following
           events:

           o Request from an upper network layer for service

           o Response to the upper layer
     FIDONEWS 13-45               Page 24                   4 Nov 1996


           o Request to the lower network layer to perform a service

           o Response from the lower layer

           o Interaction with the system and environment in which the
             protocol is implemented (e.g. timeouts, host operating system
             aborts, ...)

           A  protocol  specification, in  a large part, consists  of
           specifying state  changes  in  automata  which  model protocol
           entities  and  in describing the data which they exchange.

           For  historical  reasons,  the  term  packet  is used  in
           FidoNet  to represent a bundle of messages, as opposed to the
           more common use as a unit of communication, which is known as a
           block in FidoNet.


        4. Data Description

           A  language  specific  notation  was avoided.  Please help
           stamp  out environmental  dependencies.   Only  you  can
           prevent  PClone market dominance.  Don't panic, there are
           rectangular record layouts too.

           (* non-terminals *)
           UpperCaseName - to be defined further on

           (* literals *)
           "ABC"         - ASCII character string, no termination implied
           nnH           - byte in hexadecimal

           (* terminals *)
           someName      - 16-bit integer, low order byte first (8080
                           style)
           someName[n]   - field of n bytes
           someName[.n]  - field of n bits
           someName(n)   - Null terminated string allocated n chars (incl
                           Null)
           someName{max} - Null terminated string of up to max chars (incl
                           Null)

           (* punctuation *)
           a b           - one 'a' followed by one 'b'
           ( a | b )     - either 'a' or 'b', but not both
           { a }         - zero or more 'a's
           [ b ]         - zero or one 'b'
           (* comment *) - ignored

           (* predeclared constant *)
           Null          = 00H



      5. Finite State Machine Notation

     FIDONEWS 13-45               Page 25                   4 Nov 1996


     .-----+----------+-------------------+-------------------------+-----.
     |State | State | Predicate(s)        | Action(s)               | Next|
     |#     | Name  |                     |                         |  St |
     |-----+----------+-------------------------+-------------------------
     +-----|
     | fnn*|          |                         |
     |     | `-----+----------+-------------------------+--------------
     -----------+-----'

         State #      - Number of this state (e.g. R13).
                        f  - FSM initial (Window, Sender, Receiver, ...)
                        nn - state number
                        *  - state which represents a lower level protocol
                             which is represented by yet another
                             automation.

         State Name   - Descriptive name of this state.

         Predicate(s) - Conditions which terminate the state.  If
                        predicates are non-exclusive, consider them
                        ordered.

         Action(s)    - Action(s) corresponding to predicate(s)

         Next State   - Subsequent state corresponding to predicate(s)

         Ideally,  there  should be  a  supporting section for each  state
         which should  give a prose description of the state, its
         predicates,  actions, etc.  So much for ideals.


      B. Application Layer : the System from the User's View

         The application layer is outside the domain of a FidoNet standard,
         as it is the layer that the user's application sees as opposed to
         what FidoNet sees.   In  recent  months,  there  has been
         sufficient confusion  and discussion  about  the  format  of  data
         at this level  to  warrant  the description  of the data
         structure, the message as it is stored by Fido, SEAdog, and Rover.

         Perfectly valid FidoNet systems may be implemented whose stored
         messages differ greatly from this format.


        1. Application Layer Data Definition : a Stored Message

                                    Stored Message

            Offset
           dec hex
                   .-----------------------------------------------.
             0   0 |                                               |
                   ~                 fromUserName                  ~
                   |                   36 bytes                    |
                   +-----------------------+-----------------------+
            36  24 |                                               |
     FIDONEWS 13-45               Page 26                   4 Nov 1996


                   ~                  toUserName                   ~
                   |                   36 bytes                    |
                   +-----------------------+-----------------------+
            72  48 |                                               |
                   ~                    subject                    ~
                   |                   72  bytes                   |
                   +-----------------------+-----------------------+
           144  90 |                                               |
                   ~                    DateTime                   ~
                   |                    20 bytes                   |
                   +-----------------------+-----------------------+
           164  A4 | timesRead (low order) | timesRead (high order)|
                   +-----------------------+-----------------------+
           166  A6 | destNode (low order)  | destNode (high order) |
                   +-----------------------+-----------------------+
           168  A8 | origNode (low order)  | origNode (high order) |
                   +-----------------------+-----------------------+
           170  AA |   cost (low order)    |   cost (high order)   |
                   +-----------------------+-----------------------+
           172  AC | origNet (low order)   | origNet (high order)  |
                   +-----------------------+-----------------------+
           174  AE | destNet (low order)   | destNet (high order)  |
                   +-----------------------+-----------------------+
           176  B0 | destZone (optional)   | destZone (optional)   |
                   +-----------------------+-----------------------+
           178  B2 | origZone (optional)   | origZone (optional)   |
                   +-----------------------+-----------------------+
           180  B4 | destPoint(optional)   | destPoint(optional)   |
                   +-----------------------+-----------------------+
           182  B6 | origPoint(optional)   | origPoint(optional)   |
                   +-----------------------+-----------------------+
           184  B8 |  replyTo (low order)  |  replyTo (high order) |
                   +-----------------------+-----------------------+
           186  BA | Attribute (low order) | Attribute (high order)|
                   +-----------------------+-----------------------+
           188  BC | nextReply (low order) | nextReply (high order)|
                   +-----------------------+-----------------------+
           190  BE |                      text                     |
                   ~                    unbounded                  ~
                   |                 null terminated               |
                   `-----------------------------------------------'

           Message    = fromUserName(36)  (* Null terminated *)
                        toUserName(36)    (* Null terminated *)
                        subject(72)       (* see FileList below *)
                        DateTime          (* message body was last edited
                                             *)
                        timesRead         (* number of times msg has been
                                             read *)
                        destNode          (* of message *)
                        origNode          (* of message *)
                        cost              (* in lowest unit of originator's
                                             currency *)
                        origNet           (* of message *)
                        destNet           (* of message *)
                        destZone          (* of message *)
     FIDONEWS 13-45               Page 27                   4 Nov 1996


                        origZone          (* of message *)
                        destPoint         (* of message *)
                        origPoint         (* of message *)
                        replyTo           (* msg to which this replies *)
                        AttributeWord
                        nextReply         (* msg which replies to this *)
                        text(unbounded)   (* Null terminated *)

           DateTime   = (* a character string 20 characters long *)
                                          (* 01 Jan 86  02:34:56 *)
                        DayOfMonth " " Month " " Year " "
                        " " HH ":" MM ":" SS
                        Null

           DayOfMonth = "01" | "02" | "03" | ... | "31"  (* Fido 0 fills *)
           Month      = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" |
                        "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec"
           Year       = "01" | "02" | .. | "85" | "86" | ... | "99" | "00"
           HH         = "00" | .. | "23"
           MM         = "00" | .. | "59"
           SS         = "00" | .. | "59"

           AttributeWord   bit       meaning
                           ---       --------------------
                             0  +    Private
                             1  + s  Crash
                             2       Recd
                             3       Sent
                             4  +    FileAttached
                             5       InTransit
                             6       Orphan
                             7       KillSent
                             8       Local
                             9    s  HoldForPickup
                            10  +    unused
                            11    s  FileRequest
                            12  + s  ReturnReceiptRequest
                            13  + s  IsReturnReceipt
                            14  + s  AuditRequest
                            15    s  FileUpdateReq

                                  s - need not be recognized, but it's ok
                                  + - not zeroed before packeting

           Bits numbers ascend with arithmetic significance of bit
           position.


           Message Text

           Message text is unbounded and null terminated (note exception
           below).

           A 'hard' carriage return, 0DH,  marks the end of a paragraph,
           and must be preserved.

     FIDONEWS 13-45               Page 28                   4 Nov 1996


           So   called  'soft'  carriage  returns,  8DH,  may  mark  a
           previous processor's  automatic line wrap, and should be
           ignored.  Beware  that they may be followed by linefeeds, or may
           not.

           All  linefeeds, 0AH, should be ignored.  Systems which display
           message text should wrap long lines to suit their application.

           If the first character of a physical line (e.g. the first
           character of the  message text, or the character immediately
           after a hard carriage return (ignoring any linefeeds)) is a ^A
           (<control-A>, 01H), then that line  is  not  displayed  as  it
           contains control  information.  The convention for such control
           lines is:
             o They begin with ^A
             o They end at the end of the physical line (i.e. ignore soft
               <cr>s).
             o They begin with a keyword followed by a colon.
             o The keywords are uniquely assigned to applications.
             o They keyword/colon pair is followed by application specific
               data.

           Current ^A keyword assignments are:
     |     o TOPT <pt no> - destination point address
           o FMPT <pt no> - origin point address
           o INTL <dest z:n/n> <orig z:n/n> - used for inter-zone address


           File Specifications

           If  one  or more  of FileAttached, FileRequest, or
           FileUpdateReq  are asserted  in an AttributeWord, the
           subject{72} field is interpreted as a list of file
           specifications  which may include wildcards and other system-
           dependent data.  This list is of the form

           FileList = [ FileSpec { Sep FileSpec } ] Null

           FileSpec = (* implementation dependent file specification.  may
                         not contain Null or any of the characters in Sep.
                         *)

           Sep      = ( " " | "," )  { " " }


           There are deviations from and additions to these specifications

           1  - Fido does not necessarily terminate the message text with a
                Null, but  uses  an empty line (0DH 0AH 0DH 0AH).  Some
                Fido utilities use an EOF (1AH).

           2 - SEAdog zeros the message cost field when building a message.

           4 - SEAdog uses a different format for dates, e.g.

           DateTime   = (* a character string 20 characters long *)
     FIDONEWS 13-45               Page 29                   4 Nov 1996


                        (* SEAdog format Mon  1 Jan 86 02:34 *)
                        DayOfWk " " DayOfMo " " Month " " Year " " HH ":"
                        MM Null

           DayOfWk  = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" | "Sun"
           DayOfMo  = " 1" | " 2" | " 3" | ... | "31"  (* blank fill *)



        2. Application Layer Protocol : Schedules and Events

           At  the application level, FidoNet imposes few protocol
           requirements.  An implementation   must   automatically
           originate  and receive node-to-node  FidoNet  connections.
           Some implementations do this  in 'windows'  or  time  slots.
           Routing  of  messages  will usually  be different and
           customizable for each scheduled window.

           The ability to send to and receive from any FidoNet listed node
           during the Zone Mail Hour (eg. 9:00-10:00 UCT in Z1) is
           considered mandatory.

           Current  implementations assemble all data for outbound
           connections at the  start of a window, and  disassemble inbound
           data at the end of  a window.   Due to performance
           considerations on small machines, this is considered  a valid
           optimization.   Observe that it somewhat inhibits dynamic
           routing.


      C. Presentation Layer : the User from the System's View

        1. Presentation Layer Data Definition : the Packed Message

           To  conserve space and eliminate fields which would be
           meaningless  if sent  (e.g. timesRead), messages are packed for
           transmission.  As this is  a data structure which is actually
           transferred, its definition  is critical  to FidoNet.  A packed
           message has a number of fixed  length fields followed by four
           null terminated strings.

           While  most of the string fields in a stored message are fixed
           length, to  conserve space strings are variable length when in a
           packet.  All variable  length strings are all Null terminated,
           including especially the message text.


                                     Packed Message

            Offset
           dec hex
                   .-----------------------------------------------.
             0   0 |    0     |     2      |    0      |    0      |
                   +-----------------------+-----------------------+
             2   2 | origNode (low order)  | origNode (high order) |
                   +-----------------------+-----------------------+
     FIDONEWS 13-45               Page 30                   4 Nov 1996


             4   4 | destNode (low order)  | destNode (high order) |
                   +-----------------------+-----------------------+
             6   6 | origNet (low order)   | origNet (high order)  |
                   +-----------------------+-----------------------+
             8   8 | destNet (low order)   | destNet (high order)  |
                   +-----------------------+-----------------------+
            10   A | Attribute (low order) | Attribute (high order)|
                   +-----------------------+-----------------------+
            12   C |   cost (low order)    |   cost (high order)   |
                   +-----------------------+-----------------------+
            14   E |                                               |
                   ~                    DateTime                   ~
                   |                    20 bytes                   |
                   +-----------------------+-----------------------+
            34  22 |                  toUserName                   |
                   ~                  max 36 bytes                 ~
                   |                null terminated                |
                   +-----------------------+-----------------------+
                   |                 fromUserName                  |
                   ~                  max 36 bytes                 ~
                   |                null terminated                |
                   +-----------------------+-----------------------+
                   |                    subject                    |
                   ~                  max 72 bytes                 ~
                   |                null terminated                |
                   +-----------------------+-----------------------+
                   |                      text                     |
                   ~                    unbounded                  ~
                   |                 null terminated               |
                   `-----------------------------------------------'

           Due  to routing, the origin and  destination net and node of a
           packet are  often quite different from  those of the messages
           within it,  nor need  the origin and destination nets and nodes
           of the messages within a packet be homogenous.

           PakdMessage  = 02H 00H           (* message type, old type-1
                                               obsolete *)
                          origNode          (* of message *)
                          destNode          (* of message *)
                          origNet           (* of message *)
                          destNet           (* of message *)
                          AttributeWord
                          cost              (* in lowest unit of
                                               originator's currency *)
                          DateTime          (* message body was last edited
                                               *)
                          toUserName{36}    (* Null terminated *)
                          fromUserName{36}  (* Null terminated *)
                          subject{72}       (* Null terminated *)
                          text{unbounded}   (* Null terminated *)





     FIDONEWS 13-45               Page 31                   4 Nov 1996


      2. Presentation Layer Protocol : a Mail Window

     .-----+----------+-------------------------+------------------------.
     |State| State    | Predicate(s)            | Action(s) | Next|      |
     |  #  | Name     |                         |           | St  |      |
     |-----+----------+-------------------------+-------------------------
        | W0 | WindTop  | 1 end of window reached
                        | reset modem to not answr
                        | exit|
        |     |         | 2 time remains in window| ensure modem can answer
        | W1  | |-----+----------+-------------------------+--------
        -----------------+-----|
        | W1  | WindIdle | 1 incoming call         |
        | W2  |
        |     |          | 2 receive-only mode     |
        | W0  |
        |     |          | 3 send-only mode        |
        | W3  |
        |     |          | 4 60-180 secs & no call |
        | W3  | |-----+----------+-------------------------+---------------
        ----------+-----|
        | W2* | WindRecv |                         | (receive call R0)
        | W3  | |-----+----------+-------------------------+---------------
        ----------+-----|
        | W3  | WindCall | 1 select outgoing call  | increment try count
        | W4  |
        |     |          | 2 no outgoing calls     |
        | W0  | |-----+----------+-------------------------+---------------
        ----------+-----|
        | W4* | WindSend |                         | (make call S0)
        | W5  | |-----+----------+-------------------------+---------------
        ----------+-----|
        | W5  | WindMark | 1 call successful       | remove node fr call
        list| W0  |
        |     |          | 2 no connect            | remove if try cnt >
        lim | W0  |
        |     |          | 3 call failed           | incr conn cnt, remove
        | W0  |
        |     |          |                         |   if con cnt > lim
        |     | `-----+----------+-------------------------+---------------
        ----------+-----'


         The  length of the inter-call delay time at W1.4 is not critical.
         It is important that this not be a constant, so two systems
         calling each other do  not incur infinite busy signals.
         Sophisticated implementations  may vary  the  inter-call delay
         depending  on number of calls to  be  made, window width, user
         specification, etc.


      D. Session Layer Protocol : Connecting to Another FidoNet Machine

         A session is a connection between two FidoNet machines.  It is
         currently assumed  to be over the  DDD telephone network via
         modems.  The  calling machine starts out as the sender and the
     FIDONEWS 13-45               Page 32                   4 Nov 1996


         called machine as the receiver.  The  pickup  feature is described
         by the sender and  receiver  changing roles  midway through the
         session, after the sender has transferred  the message  packet and
         any attached files.  Due to the lack of security  in the  pickup
         protocol (danger of pickup by a fake node), a change in  the
         protocol may be expected in the near future.

         Once  a connection has been established, each system should ensure
         that the  physical connection remains  throughout the session.
         For physical layers  implemented  through modems,  this means
         monitoring the  carrier detect signal, and terminating the session
         if it is lost.

         Error  detection at the physical layer should be monitored for
         both sent and  received  characters.  Parity,  framing, and other
         physical errors should be detected.

         Sender

        .-----+----------+-------------------------+-----------------------
     --+-----.
        |State| State    | Predicate(s)            | Action(s)
     | Next|
        |  #  | Name     |                         |
        | St  | |-----+----------+-------------------------+---------------
        ----------+-----|
        | S0  | SendInit |                         | dial modem
        | S1  | |-----+----------+-------------------------+---------------
        ----------+-----|
        | S1  | WaitCxD  | 1 carrier detected      | delay 1-5 seconds
        | S2  |
        |     |          | 2 busy, etc.            | report no connection
        | exit|
        |     |          | 3 voice                 | report no carrier
        | exit|
        |     |          | 4 carrier not detected  | report no connection
        | exit|
        |     |          |   within 60 seconds     |
        |     | |-----+----------+-------------------------+---------------
        ----------+-----|
        | S2  | WhackCRs | 1 over 30 seconds       | report no response
        <cr> | exit|
        |     |          | 2 ?? <cr>s received     | delay 1 sec
        | S3  |
        |     |          | 3 <cr>s not received    | send <cr> <sp> <cr>
        <sp>| S2  |
        |     |          |                         |   delay ??? secs
        |     | |-----+----------+-------------------------+---------------
        ----------+-----|
        | S3  | WaitClear| 1 no input for 0.5 secs | send TSYNCH = AEH
        | S4  |
        |     |          | 2 over 60 seconds       | hang up, report
        garbage | exit|
        |     |          |   and line not clear    |
        |     | |-----+----------+-------------------------+---------------
        ----------+-----| | S4* | TSyncChk | 1 'C' or NAK (peeked at)|
     FIDONEWS 13-45               Page 33                   4 Nov 1996


        (XMODEM send packet XS1)| S5  |
        |     |          | 2 over 2 seconds        | eat noise, resend
        TSYNCH| S4  |
        |     |          | 3 over 30 seconds       | hang up report not
        Fido | exit| |-----+----------+-------------------------+----------
        ---------------+-----|
        | S5  | CheckMail| 1 XMODEM successful     | (Fido registers
        success)| S6  |
        |     |          | 2 XMODEM fail or timeout| hang up, report mail
        bad| exit| |-----+----------+-------------------------+------------
        -------------+-----|
        | S6* | SendFiles|                         | (BATCH send files BS0)
        | S7  | |-----+----------+-------------------------+---------------
        ----------+-----|
        | S7  | CheckFile| 1 BATCH send successful |
        | S8  |
        |     |          | 2 BATCH send failed     | hang up, rept files
        fail| exit| |-----+----------+-------------------------+-----------
        --------------+-----|
        | S8  | TryPickup| 1 wish to pickup        | note send ok
        | R2* |
        |     |          | 2 no desire to pickup   | delay 5 secs
        | exit|
        |     |          |                         |   hang up, rept send
        ok |     | `-----+----------+-------------------------+------------
        -------------+-----'

         Although  the  above  shows  the  sender  emitting only one
         TSYNCH,  it is recommended  that a timeout of 5-20 seconds should
         initiate another TSYNCH.  The receiver should tolerate multiple
         TSYNCHs.

         In state S4, the phrase "peeked at" means that the character is
         not removed from the buffer.  Therefore when XS1 is started the
         proper character for beginning the Xmodem transfer will be
         detected.

        Receiver

         The  receiving FSM is given  an external timer, the expiration of
         which will cause termination with a result of 'no calls' (R0.2).

        .-----+----------+-------------------------+-----------------------
     --+-----.
        |State| State    | Predicate(s)            | Action(s)
     | Next|
        |  #  | Name     |                         |
        | St  | |-----+----------+-------------------------+---------------
        ----------+-----|
        | R0  | WaitCxD  | 1 carrier detected      |
        | R1  |
        |     |          | 2 external timer expires| report no calls
        | exit| |-----+----------+-------------------------+---------------
        ----------+-----|
        | R1  | WaitBaud | 1 baud rate detected    | send signon with <cr>s
        | R2  |
     FIDONEWS 13-45               Page 34                   4 Nov 1996


        |     |          | 2 no detect in ?? secs  | hang up, report no
        baud | exit| |-----+----------+-------------------------+----------
        ---------------+-----|
        | R2  | WaitTsync| 1 TSYNCH received       | ignore input not
        TSYNCH | R3  |
        |     |          | 2 60 seconds timeout    | hang up, report not
        Fido| exit| |-----+----------+-------------------------+-----------
        --------------+-----|
        | R3* | RecMail  |                         | (XMODEM rec packet
        XR0) | R4  | |-----+----------+-------------------------+----------
        ---------------+-----|
        | R4  | XRecEnd  | 1 XMODEM successful     | delay 1 second
        | R5  |
        |     |          |                         |   flush input
        |     |
        |     |          | 2 XMODEM failed         | hang up, rept mail
        fail | exit| |-----+----------+-------------------------+----------
        ---------------+-----|
        | R5* | RecFiles |                         | (BATCH rec files BR0)
        | R6  | |-----+----------+-------------------------+---------------
        ----------+-----|
        | R6  | ChkFiles | 1 BATCH recv successful | delay 2 secs
        | R7  |
        |     |          | 2 BATCH recv failed     | hang up, report bad
        file| exit| |-----+----------+-------------------------+-----------
        --------------+-----| | R7  | AllowPkup| 1 have pickup for sender|
        receiver becomes sender | S3* |
        |     |          | 2 nothing to pickup     | hang up, rept recv ok
        | exit| `-----+----------+-------------------------+---------------
        ----------+-----'


      E. Transport Layer : ?????

        1. Data Definitions

        2. Transport Layer Protocol : Routing

           FidoNet   does  not  necessarily  send  a  message  directly  to
           its destination.   To reduce the number of network connections,
           mail to  a subset  of  the  nodelist  may  be  routed  to one
           node for  further distribution  within  that  subset.   In
           addition, custom routing  is possible.  Routing of a message is
           determined in one of three ways.

           o If there are files attached, then a message must be sent
             directly to its destination.

           o Messages without attached files should be routed through the
             inbound host  of the destination  node's  subnet  as specified
             by a FidoNet format nodelist.

           o To prevent overloading of inbound hosts, a system should
             provide for host routing to be disabled for a target node, or
             nodes.

     FIDONEWS 13-45               Page 35                   4 Nov 1996


      F. Network Layer : the Network's View of the System, Routing and
         Packets


        1. Network Layer Data Definition : the Packet Header

           The  packet contains messages in packed format to be transferred
           over the  net during a connection.  As this data structure is
           transferred, its definition is critical to FidoNet.

           A  packet may contain zero or more packed messages.  A packet
           without messages is often generated as a poll packet.

           Every  packet begins with a  packet header.  The fields of the
           packet header are of fixed length.


                                     Packet Header
            Offset
           dec hex
                   .-----------------------------------------------.
             0   0 | origNode (low order)  | origNode (high order) |
                   +-----------------------+-----------------------+
             2   2 | destNode (low order)  | destNode (high order) |
                   +-----------------------+-----------------------+
             4   4 |   year (low order)    |   year (high order)   |
                   +-----------------------+-----------------------+
             6   6 |  month (low order)    |  month (high order)   |
                   +-----------------------+-----------------------+
             8   8 |   day (low order)     |   day (high order)    |
                   +-----------------------+-----------------------+
            10   A |   hour (low order)    |   hour (high order)   |
                   +-----------------------+-----------------------+
            12   C |  minute (low order)   |  minute (high order)  |
                   +-----------------------+-----------------------+
            14   E |  second (low order)   |  second (high order)  |
                   +-----------------------+-----------------------+
            16  10 |   baud (low order)    |   baud (high order)   |
                   +-----------------------+-----------------------+
            18  12 |    0     |     2      |    0      |    0      |
                   +-----------------------+-----------------------+
            20  14 | origNet (low order)   | origNet (high order)  |
                   +-----------------------+-----------------------+
            22  16 | destNet (low order)   | destNet (high order)  |
                   +-----------------------+-----------------------+
            24  18 |       prodCode        |       serialNo        |
                   +-----------------------+-----------------------+
            26  1A |                                               |
                   |             password   (some impls)           |
                   |                  eight bytes                  |
                   |                  null padded                  |
                   |                                               |
                   +-----------------------+-----------------------+
            34  22 | origZone (low) (opt)  | origZone (high) (opt) |
                   +-----------------------+-----------------------+
            36  24 | destZone (low) (opt)  | destZone (high) (opt) |
     FIDONEWS 13-45               Page 36                   4 Nov 1996


                   +-----------------------+-----------------------+
            38  26 |                     fill                      |
                   ~                   20 bytes                    ~
                   |                                               |
                   +-----------------------+-----------------------+
            58  3A |                 zero or more                  |
                   ~                    packed                     ~
                   |                   messages                    |
                   +-----------------------+-----------------------+
                   |    0     |     0      |    0     |     0      |
                   `-----------------------+-----------------------'


           Packet       = PacketHeader  { PakdMessage }  00H 00H

           PacketHeader = origNode   (* of packet, not of messages in
                                        packet *)
                          destNode   (* of packet, not of messages in
                                        packet *)
                          year       (* of packet creation, e.g. 1986 *)
                          month      (* of packet creation, 0-11 for Jan-
                                        Dec *)
                          day        (* of packet creation, 1-31 *)
                          hour       (* of packet creation, 0-23 *)
                          minute     (* of packet creation, 0-59 *)
                          second     (* of packet creation, 0-59 *)
                          baud       (* max baud rate of orig and dest,
                                        0=SEA *)
                          PacketType (* old type-1 packets now obsolete *)
                          origNet    (* of packet, not of messages in
                                        packet *)
                          destNet    (* of packet, not of messages in
                                        packet *)
                          prodCode   (* 0 for Fido, write to FTSC for
                                        others *)
                          serialNo   (* binary serial number (otherwise
                                        null)*)
                          password   (* session password  (otherwise null)
                                        *)
                          origZone   (* zone of pkt sender (otherwise null)
                                        *)
                          destZone   (* zone of pkt receiver (otherwise
                                        null)*)
                          fill[20]

           PacketType   = 02H 00H  (* 01H 00H was used by Fido versions
                                      before 10 which did not support local
                                      nets.  The packed message header was
                                      also different for those versions *)

           prodCode     = (  00H      (* Fido *)
                          |  ...
                          |  ??H      (* Please apply for new codes *)
                          )


     FIDONEWS 13-45               Page 37                   4 Nov 1996


           The  remainder of the packet consists of packed messages.  Each
           packed message  begins  with  a  message type word 0200H.   A
           pseudo-message beginning with the word 0000H signifies the end
           of the packet.


        2. Network Layer Data Description : a File with Attributes

           The  BATCH  protocol uses  the MODEM7 filename and TeLink/XMODEM
           file transfer protocols to transfer the file with attributes.

           When  a  file is transferred via  FidoNet, an attempt is made to
           also pass  the operating system's attributes  for the file such
           as  length, modification  date, etc.  FidoNet does this via a
           special prefix block to  the XMODEM file transfer using a
           protocol known as TeLink.  As the TeLink  protocol relies on a
           modification to the XMODEM file  transfer protocol, it is
           documented at the data link layer level.

           The  MODEM7 file name is redundant if there is also a TeLink
           block, in which case the name may be taken from either or both.

                                   FileName as Sent
            Offset
           dec hex
                   .-----------------------------------------------.
             0   0 |                   fileName                    |
                   ~                   8  bytes                    ~
                   |           left adjusted blank filled          |
                   +-----------------------+-----------------------+
             8   8 |                    fileExt                    |
                   ~                    3  bytes                   ~
                   |           left adjusted blank filled          |
                   `-----------------------------------------------'


      3. Network Layer Protocol : BATCH File Finite State Machines


         BATCH File Sender

        .-----+----------+-------------------------+-----------------------
     --+-----.
        |State| State    | Predicate(s)            | Action(s)
     | Next|
        |  #  | Name     |                         |
        | St  | |-----+----------+-------------------------+---------------
        ----------+-----|
        | BS0*| MoreFiles| 1 more files to send    | (MODEM7 FName send
        MS0) | BS1 |
        |     |          | 2 no more files to send |
        | BS3 | |-----+----------+-------------------------+---------------
        ----------+-----|
        | BS1 | CheckFNm | 1 MODEM7 Filename ok    | (TeLink send file XS0)
        | BS2 |
        |     |          | 2 MODEM7 Filename bad   | report name send bad
     FIDONEWS 13-45               Page 38                   4 Nov 1996


        | exit| |-----+----------+-------------------------+---------------
        ----------+-----|
        | BS2 | CheckFile| 1 TeLink send ok        |
        | BS0 |
        |     |          | 2 TeLink send bad       | report file send bad
        | exit| |-----+----------+-------------------------+---------------
        ----------+-----| | BS3 | EndSend  | 1 rec NAK for next file | send
        EOT, report send ok| exit|
        |     |          | 2 10 seconds no NAK     | send EOT, report no
        NAK | exit| `-----+----------+-------------------------+-----------
        --------------+-----'

         When  no files remain, the sender responds to the receiver's NAK
         with an EOT.  The EOT is not ACK/NAKed by the receiver.

         Filenames  must be upper case ASCII.  The data link layer uses "u"
         as  a control character.


         BATCH File Receiver

        .-----+----------+-------------------------+-----------------------
     --+-----.
        |State| State    | Predicate(s)            | Action(s)
     | Next|
        |  #  | Name     |                         |
        | St  | |-----+----------+-------------------------+---------------
        ----------+-----|
        | BR0*| RecvName |                         | (MODEM7 FName recv
        MR0) | BR1 | |-----+----------+-------------------------+----------
        ---------------+-----|
        | BR1 | CheckFNm | 1 MODEM7 no more files  | report files recd ok
        | exit|
        |     |          | 2 MODEM7 Filename ok    | (TeLink recv file XR0)
        | BR2 |
        |     |          | 2 MODEM7 Filename bad   | report name recv bad
        | exit| |-----+----------+-------------------------+---------------
        ----------+-----|
        | BR2 | CheckFile| 1 TeLink recv ok        |
        | BR0 |
        |     |          | 2 TeLink recv bad       | report file recv bad
        | exit| `-----+----------+-------------------------+---------------
        ----------+-----'


      G. Data Link Layer : Error-Free Data Transfer

        1. Data Link Layer Data Definition : XMODEM/TeLink Blocks

           XMODEM  transfers  are  in  blocks  of 128  uninterpreted  data
           bytes preceded  by  a three  byte header  and followed by either
           a one  byte checksum  or a two byte crc remainder.  XMODEM makes
           no provision  for data  streams  which  are  not  an  integral
           number  of  blocks  long.  Therefore,  the sender pads streams
           whose length is not a multiple  of 128 bytes with the end-of-
           file character (^Z for MS-DOS), and use some other  means  to
     FIDONEWS 13-45               Page 39                   4 Nov 1996


           convey  the  true data length to the receiver  (e.g.  TeLink
           file info block).

           Data blocks contain sequence numbers so the receiver can ensure
           it has the  correct block.  Block  numbers are sequential
           unsigned eight  bit integers  beginning with 01H and wrapping to
           00H, except that a TeLink block is given sequence number 00H.

           For  files which are attached to the mail packet, not the mail
           packet itself,  if the sending system is aware of the file
           attributes as they are  known to the operating system, then the
           first block of the XMODEM transfer  may be a special TeLink
           block to transfer that information.  This  block  differs  in
           that  the  first byte is a SYN  character  as opposed  to an
           SOH, and it is always sent checksum as opposed to CRC.  Should
           the receiver be unwilling to handle such information, after two
           NAKs (or "C"s), the sender skips this special block and goes on
           to the data itself.



                             XMODEM Data Block (CRC mode)
            Offset
           dec hex
                   .-----------------------------------------------.
             0   0 |        SOH  -  Start Of Header -  01H         |
                   +-----------------------------------------------+
             1   1 |                 BlockNumber                   |
                   +-----------------------------------------------+
             2   2 |               BlockComplement                 |
                   +-----------------------------------------------+
             3   3 |                128 bytes  of                  |
                   ~                uninterpreted                  ~
                   |                    data                       |
                   +-----------------------------------------------+
           131  83 |             CRC high order byte               |
                   +-----------------------------------------------+
           132  84 |             CRC  low order byte               |
                   `-----------------------------------------------'



                           XMODEM Data Block (Checksum mode)
            Offset
           dec hex
                   .-----------------------------------------------.
             0   0 |        SOH  -  Start Of Header -  01H         |
                   +-----------------------------------------------+
             1   1 |                 BlockNumber                   |
                   +-----------------------------------------------+
             2   2 |               BlockComplement                 |
                   +-----------------------------------------------+
             3   3 |                128 bytes  of                  |
                   ~                uninterpreted                  ~
                   |                    data                       |
                   +-----------------------------------------------+
     FIDONEWS 13-45               Page 40                   4 Nov 1996


           131  83 |                Checksum byte                  |
                   `-----------------------------------------------'


                            TeLink File Descriptor Block
            Offset
           dec hex
                   .-----------------------------------------------.
             0   0 |       SYN  -  File Info Header -  16H         |
                   +-----------------------------------------------+
             1   1 |                     00H                       |
                   +-----------------------------------------------+ data
     offset
             2   2 |                     FFH                       | dec
     hex           +-----------------------------------------------+
             3   3 |     File Length, least significant byte       |  0
                 0 +-----------------------------------------------+
             4   4 | File Length, second to least significant byte |  1
                   1 +-----------------------------------------------+
             5   5 |  File Length, second to most significant byte |  2
                   2 +-----------------------------------------------+
             6   6 |      File Length, most significant byte       |  3
                   3 +-----------------------------------------------+
             7   7 |            Creation Time of File              |  4
     4
                   |                "DOS Format"                   |
                   +-----------------------------------------------+
             9   9 |            Creation Date of File              |  6
     6
                   |                "DOS Format"                   |
                   +-----------------------------------------------+
            11   B |                 File  Name                    |  8
     8
                   ~                  16 chars                     ~
                   |        left justified  blank filled           |
                   +-----------------------------------------------+
            27  1B |                    00H                        | 24
                   18 +-----------------------------------------------+
            28  1C |            Sending Program Name               | 25
     19
                   ~                  16 chars                     ~
                   |         left justified  Null filled           |
                   +-----------------------------------------------+
            44  2C |            01H (for CRC) or 00H               | 41
                   29 +-----------------------------------------------+
            45  2D |                    fill                       | 42
     2A
                   ~                  86 bytes                     ~
                   |                  all zero                     |
                   +-----------------------------------------------+
           132  84 |                Checksum byte                  |
                   `-----------------------------------------------'



           XMODEMData   = XMODEMBlock      (* block of data with header and
     FIDONEWS 13-45               Page 41                   4 Nov 1996


                                              trailer *)
                          | TeLinkBlock    (* TeLink File Descriptor Block
                                              *)
                          | ACK            (* acknowledge data received ok
                                              *)
                          | NAK            (* negative ACK & poll 1st block
                                              *)
                          | EOT            (* end of xfer, after last block
                                              *)
                          | "C"            (* 43H *)

           XMODEMBlock  = SOH              (* Start of Header, XMODEM Block
                                              *)
                          blockNumber[1]   (* sequence, i'=mod( i+1, 256 )
                                              *)
                          blockCompl[1]    (* one's compl of BlockNumber *)
                          data[128]        (* uninterpreted user data block
                                              *)
                          (CRC | Checksum) (* error detect/correction code
                                              *)

           TeLinkBlock  = SYN              (* File Info Header *)
                          00H              (* block no, must be first block
                                              *)
                          FFH              (* one's complement of block no
                                              *)
                          fileLength[4]    (* length of data in bytes *)
                          CreationTime[2]  (* time file last modified or
                                              zero *)
                          CreationDate[2]  (* date file last modified or
                                              zero *)
                          fileName(16)     (* name of file, not vol or dir
                                              *)
                          00H              (* header version number *)
                          sendingProg(16)  (* name of program on send side
                                              *)
                          crcMode[1]       (* 01H for CRC 00H for Checksum
                                              *)
                          fill[87]         (* zeroed *)
                          Checksum         (* error detect/correction code
                                              *)

           ACK          = 06H              (* acknowledge data received ok
                                              *)
           NAK          = 15H              (* negative ACK & poll 1st block
                                              *)
           SOH          = 01H              (* start of header, begins block
                                              *)
           SYN          = 16H              (* start of TeLink file info blk
                                              *)
           EOT          = 04H              (* end of xfer, after last block
                                              *)
           CRC          = crc[2]           (* CCITT Cyclic Redundancy Check
                                              *)
           Checksum     = checksum[1]      (* low 8 bits of sum of data
                                              bytes using unsigned 8 bit
     FIDONEWS 13-45               Page 42                   4 Nov 1996


                                              arithmetic *)
           CreationDate = year[.7]         (* 7 bits, years since 1980, 0-
                                              127  *)
                          month[.4]        (* 4 bits, month of year, 1-12
                                              *)
                          day[.5]          (* 5 bits, day of month, 1-31 *)

           CreationTime = hour[.5]         (* 5 bits, hour of day, 0-23 *)
                          minute[.6]       (* 6 bits, minute of hour, 0-60
                                              *)
                          biSeconds[.2]    (* 6 bits, seconds/2, 0-29 *)


           Note  that the crcMode is always set to 01H in current
           implementations as  all TeLink/XMODEM implementations use the
           CRC method.  Therefore, it is always set to 01H by the sender,
           and is ignored by the receiver.


      2. Data Link Layer Protocol : XMODEM/TeLink Finite State Machines

         The  protocol is receiver driven, the receiver polling the sender
         for each  block.   If the receiver polls  for the first block
         using a "C" (43H)  as  the poll character,  it would prefer to
         have the  CRC-CCITT polynomial  remainder error detection code at
         the end of each block as opposed  to a one byte unsigned checksum.
         The sender will respond  to the  "C"  poll iff it can  comply.  If
         the sender chooses checksum as opposed  to  CRC, it waits for  the
         receiver to poll with  NAK (15H).  Should  the  checksum method be
         preferable to the receiver, it  polls with NAK rather than "C".

         The sender returns an EOT instead of a data block when no data
         remain.

         Neither  the  sender nor the  receiver should send the block or
         ACK/NAK response  while there is data being received.  They should
         wait for  the line to settle, and possibly time out.

         It  is  suggested that one's  input buffer be cleared immediately
         after sending  block or ACK/NAK response, before waiting for the
         response from the  other  end.  This  clears  any line garbage
         which  occurred during transmit.


         XMODEM/TeLink Sender

        .-----+----------+-------------------------+-----------------------
     --+-----.
        |State| State    | Predicate(s)            | Action(s)
     | Next|
        |  #  | Name     |                         |
        | St  | |-----+----------+-------------------------+---------------
        ----------+-----|
        | XS0 | WaitTeLnk| 1 over 40-60 seconds    | report sender timeout
        | exit|
        |     |          | 2 over 2 tries          | note TeLink block
     FIDONEWS 13-45               Page 43                   4 Nov 1996


        failed| XS1 |
        |     |          | 3 NAK or "C" received   | send TeLink, incr
        tries | XS0 |
        |     |          | 4 ACK received          | TeLink ok, set
        crc/cksm | XS2 | |-----+----------+-------------------------+------
        -------------------+-----|
        | XS1 | WaitStart| 1 over 40-60 seconds    | report sender timeout
        | exit|
        |     |          | 2 over 20 tries         | report send failed
        | exit|
        |     |          | 3 NAK received          | set checksum mode
        | XS2 |
        |     |          | 4 "C" recd, I can crc   | set crc mode
        | XS2 |
        |     |          | 5 "C" recd, I can't crc |
        | XS1 | |-----+----------+-------------------------+---------------
        ----------+-----|
        | XS2 | SendBlock| 1 more data available   | send next data block
        | XS3 |
        |     |          |                         |   as checksum or crc
        |     |
        |     |          | 2 last block has gone   | send EOT
        | XS4 | |-----+----------+-------------------------+---------------
        ----------+-----|
        | XS3 | WaitACK  | 1 10 retries or 1 minute| report send failed
        | exit|
        |     |          | 2 ACK received          |
        | XS2 |
        |     |          | 3 NAK (or C if 1st blk) | resend last block
        | XS3 | |-----+----------+-------------------------+---------------
        ----------+-----|
        | XS4 | WaitEnd  | 1 10 retries or 1 minute| report send failed
        | exit|
        |     |          | 2 ACK received          | report send successful
        | exit|
        |     |          | 3 NAK received          | resend EOT
        | XS4 | `-----+----------+-------------------------+---------------
        ----------+-----'


         XMODEM/TeLink Receiver

        .-----+----------+-------------------------+-----------------------
     --+-----.
        |State| State    | Predicate(s)            | Action(s)
     | Next|
        |  #  | Name     |                         |
        | St  | |-----+----------+-------------------------+---------------
        ----------+-----|
        | XR0 | RecStart | 1 prefer crc mode       | Send "C"
        | XR1 |
        |     |          | 2 want checksum mode    | send NAK
        | XR1 | |-----+----------+-------------------------+---------------
        ----------+-----| | XR1 | WaitFirst| 1 10 retries or 1 minute|
        report receive failure  | exit|
        |     |          | 2 > 3 retries or 30 secs| set want checksum mode
     FIDONEWS 13-45               Page 44                   4 Nov 1996


        | XR0 |
        |     |          | 3 EOT received          | delay < sec, purge
        input| exit|
        |     |          |                         | send ACK, report no
        file|     |
        |     |          | 4 TeLink block recd     | send ACK, set crc/cksm
        | XR2 |
        |     |          | 5 data block recd       | send ACK, set crc/cksm
        | XR2 |
        |     |          | 6 bad block or 2-10 secs| incr retry count
        | XR0 | |-----+----------+-------------------------+---------------
        ----------+-----| | XR2 | WaitBlock| 1 10 retries or 1 minute|
        report receive failure  | exit|
        |     |          | 2 EOT received          | send ACK, report recd
        ok| exit|
        |     |          |                         | send ACK, report recd
        ok|     |
        |     |          | 3 data block received   | send ACK
        | XR2 |
        |     |          | 4 bad block or 2-10 secs| send NAK, incr retry
        cnt| XR2 | `-----+----------+-------------------------+------------
        -------------+-----'


         A  number of checks should be made to ensure a valid data block
         has been received.

         o  The  physical  layer  should  have encountered no errors,  e.g.
            parity, framing, etc.

         o  The length of the block should not be less than expected.

         o  If  the blocks sequence  number does not match the  complement,
            then respond with a NAK and attempt to read the block again.

         o  If the block's sequence number is one previous (remember wrap
            around) to that of the expected block, respond with an ACK and
            read again.

         o  If the sequence number fits neither of the above criteria, and
            is yet not the expected sequence number, abort the receive.

         o  The checksum or CRC should be correct.



      3. Data Link Layer Protocol : MODEM7 Filename Finite State Machines


         MODEM7 Filename Sender

        .-----+----------+-------------------------+-----------------------
     --+-----.
        |State| State    | Predicate(s)            | Action(s)
     | Next|
        |  #  | Name     |                         |
     FIDONEWS 13-45               Page 45                   4 Nov 1996


        |  St | |-----+----------+-------------------------+---------------
        ----------+-----|
        | MS0 | WaitNak  | 1 20 retries or 1 minute| filename send failed
        | exit|
        |     |          | 2 NAK received          | send ACK & 1st ch of
        fn | MS1 |
        |     | (note 1) | 3 C received            | return fn skipped
        | exit| |-----+----------+-------------------------+---------------
        ----------+-----|
        | MS1 | WaitChAck| 1 ACK rcd, fname done   | send SUB = 1AH
        | MS2 |
        |     |          | 2 ACK rcd, fname ~done  | send next ch of fname
        | MS1 |
        |     |          | 3 other char or 1 sec   | send "u", incr retry
        cnt| MS0 | |-----+----------+-------------------------+------------
        -------------+-----|
        | MS2 | WaitCksm | 1 cksum recd and ok     | send ACK, report fn ok
        | exit|
        |     |          | 2 cksum recd but bad    | send "u", incr retry
        cnt| MS0 |
        |     |          | 3 no cksum in 1 sec     | send "u", incr retry
        cnt| MS0 | `-----+----------+-------------------------+------------
        -------------+-----'


         MODEM7 Filename Receiver

        .-----+----------+-------------------------+-----------------------
     --+-----.
        |State| State    | Predicate(s)            | Action(s)
     | Next|
        |  #  | Name     |                         |
        |  St | |-----+----------+-------------------------+---------------
        ----------+-----| | MR0 | SendNak  | 1 20 tries or 1 minute  |
        report filename failure | exit|
        |     |          | 2                       | send NAK, incr try cnt
        | MR1 | |-----+----------+-------------------------+---------------
        ----------+-----|
        | MR1 | WaitAck  | 1 rcd ACK               |
        | MR2 |
        |     |          | 2 rcd EOT               | report no files remain
        | exit|
        |     |          | 3 5 secs & no ACK/EOT   |
        | MR0 | |-----+----------+-------------------------+---------------
        ----------+-----| | MR2 | WaitChar | 1 recd EOT (can happen?)|
        report no files remain  | exit|
        |     |          | 2 recd SUB              | send checksum byte
        | MR3 |
        |     |          | 3 recd "u"              |
        | MR0 |
        |     |          | 4 recd char of name     | send ACK
        | MR2 |
        |     |          | 5 no char in 1 second   |
        | MR0 | |-----+----------+-------------------------+---------------
        ----------+-----| | MR3 | WaitOkCk | 1 recd ACK within 1 sec |
        report recd filename ok | exit|
     FIDONEWS 13-45               Page 46                   4 Nov 1996


        |     |          | 2 recd "u" or other char|
        | MR0 | `-----+----------+-------------------------+---------------
        ----------+-----'

         SUB  is the ASCII character ^Z or 1AH.  The checksum is the
         unsigned low order eight bits of the sum of the characters in the
         transferred filename including the SUB.

         Although  one second timeouts are used successfully by Fido and
         SEAdog, some fear that this is too small a timeout for some
         satellite and packet network links.

         Note 1 - MS0.3 is a common addition to accommodate a common
                  noncompliance.  Support of MS0.3 is optional for a
                  compliant mailer.  This hack also requires modification
                  of a number of state tables, see FSC-0011.


      H. Physical Layer : the Actual Connection of Two FidoNet Systems

         Will  one of the more hardware-oriented comm types give me some
         idea  of what's needed here?  Can we leave it open enough to allow
         implementation over a non-dial net?  Thanks.


      I. Revisions since FTS-0001

         89 Oct 25 (rev 13)
           o packet header: optional serialNo, password, and orig/dest zone
           o stored message to/from zone/point info added as option per
             Fido-12 and Dutchie
           o XR1 and XR2 changes per FSC-0011
           o reference to FSC-0011 for the MODEM7-avoidance hack, MS0.3
           o dropped enumeration of product codes
           o S4 modification from FSC-0011
           o Nodelist and EID reference appropriate documents
           o various cosmetics
         90 July 1-5 (rev 14)
           o spelling errors caught by Ray Gardner
           o references to the now dead IFNA elided
           o offset at end of Packed Message was 10 as opposed to 20 bytes
           o Packed Message and Packet Header corrections by Roland
             Gautschi
           o Offsets in TeLink header caught by Rick Moore
         90 August 30 (rev 15)
           o corrected offsets in packet header
         95 September 30 (rev 16)
           o TOPT corrected
           o contact info changed


      J. Acknowledgements

         Ben  Baker,  Thom  Henderson,  Tom  Jennings,  Ken Kaplan, and
         Gee Wong suggested, informed,  reviewed, and  encouraged.   Tom
         and Thom gave me all the basics, and even allowed me to look at
     FIDONEWS 13-45               Page 47                   4 Nov 1996


         actual code.  Bob Hartman was  foolish  enough  to implement  the
         specification, and was generous with useful feedback.  Ray
         Gardner caught  my  spelling errors <blush>, and Roland Gautschi
         and Rick Moore found offset and length errors.

         My employer, Pacific Systems Group was kind enough to donate my
         time to research and to write this document.

         Fido and FidoNet are registered trademarks of Tom Jennings.

         SEAdog is a trademark of System Enhancement Associates.


      K. Bibliography

         Documentation  for the protocols  and data formats are scattered.
         Some are  unattributed, some even untitled.

         Anonymous, changes to MODEM to implement CRC option  XMDM-CRC.TXT

         Baker, Ken and Moore, Rick, Nodelist Definition, currently FTS-
         0005

         Christensen, Ward, "MODEM Protocol Overview" of 1 January 82
         XMODEM.TXT

         Hartman, Bob, "Some thoughts that I had on FSC001", FSC-0011

         Henderson, Thom, "SEAdog Electronic Mail System Version 3" of
         April 86

         International  Standards Organization,  "Data Processing - Open
         Systems Interconnection - Basic Reference Model"  ISO/DIS 7498
         April 82

         Jennings,   Tom,  "FidoNet  Electronic  Mail  Protocol"  8
         February  85 FIDOMAIL.DOC

         Jennings,   Tom,  "Fido's  Internal  Structures"  of  13
         September  85 STRUCT.TXT aka STRUCT.APX

         Jennings, Tom, "Extending XMODEM/MODEM File Transfer Protocol to
         support DOS" 20 September 83   FILEXFER.DOC

         Jordan, Larry, "XMODEM File Transfer Protocol"  XMDM-LJ.TXT

         Rudin,   H   and   West,  C,  "Protocol  Specification,   Testing,
         and Verification,  III" Proceedings of  the IFIP WG 6.1 Third
         International Workshop   on   Protocol  Specification,  Testing,
         and Verification, Rueschlikon Switzerland 31 May - 2 June 1983.

         Tanenbaum, Andrew, "Computer Networks" Prentice Hall 1981

         Messages generated by Fido 11w, SEAdog 3.8, and QMail 1.01

     -----------------------------------------------------------------
     FIDONEWS 13-45               Page 48                   4 Nov 1996


     =================================================================
                            COORDINATORS CORNER
     =================================================================


     Nodelist-statistics as seen from Zone-2 for day 306
     By Ward Dossche, 2:292/854
        ZC/2

      +----+------+------------+------------+------------+------------+--+
      |Zone|Nl-278|Nodelist-285|Nodelist-292|Nodelist-299|Nodelist-306|%%|
      +----+------+------------+------------+------------+------------+--+
      |  1 | 11826|11666  -160 |11666     0 |11555  -111 |11332  -223 |37|
      |  2 | 16394|16341   -53 |16356    15 |16324   -32 |16307   -17 |54|
      |  3 |   951|  950    -1 |  956     6 |  954    -2 |  954     0 | 3|
      |  4 |   629|  610   -19 |  620    10 |  620     0 |  624     4 | 2|
      |  5 |   100|   97    -3 |   97     0 |   97     0 |   95    -2 | 0|
      |  6 |  1020| 1022     2 | 1020    -2 | 1020     0 | 1007   -13 | 3|
      +----+------+------------+------------+------------+------------+--+
           | 30920|30686  -234 |30715    29 |30570  -145 |30319  -251 |
           +------+------------+------------+------------+------------+

     -----------------------------------------------------------------

     FIDONEWS 13-45               Page 49                   4 Nov 1996


     =================================================================
                                 NET HUMOR
     =================================================================


     From: "Mike Riddle" <[e-mail]>
     To: "Baker, Christopher" <[e-mail] (Christopher Baker)>
     Date: Fri, 01 Nov 96 11:24:17 -0500
     Reply-To: "Mike Riddle" <[e-mail]>
     Subject: Re: Conmputer people...

     On Fri, 1 Nov 1996 09:39:52 -0600 (CST), Terry Begley, Information
     Technology Coordinator wrote:

     Date: Fri, 1 Nov 1996 09:12:54 EST
     From: Alex Demenschonok <[e-mail]>
     To: [e-mail]
     Subject: Re: smtp/pop3/dns server for WNT

     On  1 Nov 96 at 8:35, Michael A. Mandel wrote:

     > A normal person being what?  A non-computer systems expert?  I'm not
     > sure if that means we're better than "normal persons", but if it is,
     > hey that's o.k. too!

     hi,

     i think he means following :-) ....

      Computer experts consider themselves well dressed if their socks
      match.

      Computer experts buy their spouses a set of matched screwdrivers for
      their birthday.

      Computer experts wear moustaches or beards for "efficiency". Not
      because they're lazy.

      Computer experts have a non-technical vocabulary of 800 words.

      Computer experts think a "biting wit" is their fox terrier.

      Computer experts repair their own cameras, telephones, televisions,
      watches, and automatic transmissions.

      Computer experts say "It's 70 degrees Fahrenheit, 25 degrees Celsius,
      and 298 degrees Kelvin" and all you say is "Isn't it a nice day"

      Computer experts give you the feeling you're having a conversation
      with a dial tone or busy signal.

      Computer experts wear badges so they don't forget who they
      are. Sometimes a note is attached saying "Don't offer me a ride
      today. I drove my own car".

      Computer experts' politics run towards acquiring a parking space with
     FIDONEWS 13-45               Page 50                   4 Nov 1996


      their name on it and an office with a window.

      Computer experts know the "ABC's of Infrared" from A to B.

      Computer experts rotate their tires for laughs.

      Computer experts' briefcases contain a Phillips screwdriver, a copy
      of "C/C++", and a half of a peanut butter sandwich.

      Computer experts don't find the above at all funny.

     Cheers !

     -----
                 Terry Begley, Information Technology Coordinator
             Creighton University, College of Business Administration
               2500 California Plaza   Omaha, NE  68178  USA, Earth
            [e-mail]  402.280.2619  http://eden.creighton.edu

                   Member of the NonSequitur society.  Our motto:
           "We don't have regular meetings, but isn't blue a nice color?"

     -----------------------------------------------------------------

     FIDONEWS 13-45               Page 51                   4 Nov 1996


     =================================================================
                                  NOTICES
     =================================================================

                                Future History

      5 Nov 1996
        Election day, U.S.A.

      5 Nov 1996
        Guy Fawkes Day, England.

      1 Dec 1996
        Twelfth Anniversary of FidoNews Volume 1, Issue 1.

     12 Dec 1996
        Constitution Day, Russia

     26 Jan 1997
        Australia Day, Australia.

      6 Feb 1997
        Waitangi Day, New Zealand.

     16 Feb 1997
        Eleventh Anniversary of invention of Echomail by Jeff Rush.

     29 Feb 1997
        Nothing will happen on this day.

     25 May 1997
        Independence Day, Argentina

     11 Jun 1997
        Independence Day, Russia

      1 Dec 1998
        Fifteenth Anniversary of release of Fido version 1 by
        Tom Jennings.

     31 Dec 1999
        Hogmanay, Scotland. The New Year that can't be missed.

     15 Sep 2000
        Sydney (Australia) Summer Olympiad opens.

     -- If YOU have something which you would like to see in this
        Future History, please send a note to the FidoNews Editor.

     -----------------------------------------------------------------

     FIDONEWS 13-45               Page 52                   4 Nov 1996


     =================================================================
                         FIDONET SOFTWARE LISTING
     =================================================================


     Latest Greatest Software Versions
     by Peter E. Popovich, 1:363/264

     Still catching up from last week's crash. I should be up-to-date by
     next week's issue.

     Phased out this week: QNX Software

     Phase-out highlights:
       This week: Kitten 1.01 Software Deadline for info: 15 Nov 1996.
       Last week: Atari ST/TT Software Deadline for info: 8 Nov 1996.

     -=- Snip -=-

     Submission form for the Latest Greatest Software Versions column

     OS Platform                             :
     Software package name                   :
     Version                                 :
     Function(s) - BBS, Mailer, Tosser, etc. :
     Freeware / Shareware / Commercial?      :
     Author / Support staff contact name     :
     Author / Support staff contact node     :
     Magic name (at the above-listed node)   :

     Please include a sentence describing what the package does.

     Please send updates and suggestions to: Peter Popovich, 1:363/264

     -=- Snip -=-

     MS-DOS:
     Program Name   Version    F C Contact Name      Node        Magic Name
     ----------------------------------------------------------------------
     Act-Up         4.6        G D Chris Gunn        1:15/55     ACT-UP
     ALLFIX         4.33       T S Harald Harms      2:281/415   ALLFIX
     Announcer      1.1        O S Peter Karlsson    2:206/221   ANNOUNCE
     BGFAX          1.60       O S B.J. Guillot      1:106/400   BGFAX
     CheckPnt       0.5 beta   O F Michiel van der Vlist
                                                     2:500/9     CHECKPNT
     FidoBBS (tm)   12u        B S Ray Brown         1:1/117     FILES
     FrontDoor      2.12       M S JoHo              2:201/330   FD
     FrontDoor      2.20c      M C JoHo              2:201/330   FDINFO
     GIGO           07-14-96   G S Jason Fesler      1:1/141     INFO
     Imail          1.75       T S Michael McCabe    1:297/11    IMAIL
     ImCrypt        1.04       O F Michiel van der Vlist
                                                     2:500/9     IMCRYPT
     InfoMail       1.11       O F Damian Walker     2:2502/666  INFOMAIL
     InterEcho      1.19       T C Peter Stewart     1:369/35    IEDEMO
     InterMail      2.29k      M C Peter Stewart     1:369/35    IMDEMO
     InterPCB       1.52       O S Peter Stewart     1:369/35    INTERPCB
     FIDONEWS 13-45               Page 53                   4 Nov 1996


     IPNet          1.11       O S Michele Stewart   1:369/21    IPNET
     Jelly-Bean     1.01       T S Rowan Crowe       3:635/727   JELLY
     Jelly-Bean/386 1.01       T S Rowan Crowe       3:635/727   JELLY386
     MakePl         1.8        N F Michiel van der Vlist
                                                     2:500/9     MAKEPL
     Marena         1.1 beta   O F Michiel van der Vlist
                                                     2:500/9     MARENA
     Maximus        3.01       B P Tech              1:249/106   MAX
     McMail         1.0g5      M S Michael McCabe    1:1/148     MCMAIL
     MDNDP          1.18       N S Bill Doyle        1:388/7     MDNDP
     MsgEd          4.00       O G Paul Edwards      3:711/934   MSGED
     Opus CBCS      1.73a      B P Christopher Baker 1:374/14    OPUS
     O/T-Track      2.63a      O S Peter Hampf       2:241/1090  OT
     PcMerge        2.7        N F Michiel van der Vlist
                                                     2:500/9     PCMERGE
     PlatinumXpress 1.1        M C Gary Petersen     1:290/111   PX11TD.ZIP
     RAR            2.00       C S Ron Dwight        2:220/22    RAR
     RemoteAccess   2.50       B S Mark Lewis        1:3634/12   RA
     Silver Xpress
       Door         5.4        O S Gary Petersen     1:290/111   FILES
       Reader       4.3        O S Gary Petersen     1:290/111   SXR43.ZIP
     Squish         1.11       T P Tech              1:249/106   SQUISH
     StealTag UK    1.c...     O F Fred Schenk       2:284/412   STEAL_UK
     StealTag NL    1.c...     O F Fred Schenk       2:284/412   STEAL_NL
     T-Mail         2.599I     M S Ron Dwight        2:220/22    TMAIL
     Terminate      4.00       O S Bo Bendtsen       2:254/261   TERMINATE
     Tobruk         0.33       T G Paul Edwards      3:711/934   TOBRUK
     TriBBS         10.0       B S Patrick Driscoll  1:372/19    TRIBBS
     TriDog         10.0       M S Patrick Driscoll  1:372/19    TRIDOG
     TriToss        10.0       T S Patrick Driscoll  1:372/19    TRITOSS
     WWIV           4.24a      B S Craig Dooley      1:376/126   WWIV
     XRobot         3.01       O S JoHo              2:201/330   XRDOS

     OS/2:
     Program Name   Version    F C Contact Name      Node        Magic Name
     ----------------------------------------------------------------------
     BGFAX          1.60       O S B.J. Guillot      1:106/400   BGFAX
     FleetStreet    1.18       O S Michael Hohner    2:2490/2520 FLEET
     GIGO           07-14-96   G S Jason Fesler      1:1/141     INFO
     ImCrypt        1.04       O F Michiel van der Vlist
                                                     2:500/9     IMCRYPT
     Maximus        3.01       B P Tech              1:249/106   MAXP
     MsgEd          4.00       O G Paul Edwards      3:711/934   MSGED
     PcMerge        2.3        N F Michiel van der Vlist
                                                     2:500/9     PCMERGE
     RAR            2.00       C S Ron Dwight        2:220/22    RAR2
     Squish         1.11       T P Tech              1:249/106   SQUISHP
     T-Mail         2.599I     M S Ron Dwight        2:220/22    TMAIL2
     Tobruk         0.33       T G Paul Edwards      3:711/934   TOBRUK
     XRobot         3.01       O S JoHo              2:201/330   XROS2

     Windows (16-bit apps):
     Program Name   Version    F C Contact Name      Node        Magic Name
     ----------------------------------------------------------------------
     BeeMail        1.0        M C Andrius Cepaitis  2:470/1     BEEMAIL

     FIDONEWS 13-45               Page 54                   4 Nov 1996


     Windows (32-bit apps):
     Program Name   Version    F C Contact Name      Node        Magic Name
     ----------------------------------------------------------------------
     BeeMail        1.0        M C Andrius Cepaitis  2:470/1     BEEMAIL
     Maximus        3.01       B P Tech              1:249/106   MAXN
     PlatinumXpress 2.00       M C Gary Petersen     1:290/111   PXW-INFO
     T-Mail         2.599I     M S Ron Dwight        2:220/22    TMAILNT

     Unix:
     Program Name   Version    F C Contact Name      Node        Magic Name
     ----------------------------------------------------------------------
     ifmail         2.8f       M G Eugene Crosser    2:293/2219  IFMAIL
     ifmail-tx      2.8f-tx7.7 M G Pablo Saratxaga   2:293/2219  IFMAILTX
     MsgEd          4.00       O G Paul Edwards      3:711/934   MSGED
     Tobruk         0.33       T G Paul Edwards      3:711/934   TOBRUK

     Amiga:
     Program Name   Version    F C Contact Name      Node        Magic Name
     ----------------------------------------------------------------------
     CrashMail      1.23       T X Fredrik Bennison  2:205/324   CRASHMAIL
     CrashTick      1.1        O F Fredrik Bennison  2:205/324   CRASHTICK
     MsgEd          4.00       O G Paul Edwards      3:711/934   MSGED
     Tobruk         0.33       T G Paul Edwards      3:711/934   TOBRUK

     Function: B-BBS, M-Mailer, N-Nodelist, G-Gateway, T-Tosser,
               C-Compression, O-Other. Note: Multifunction will be listed
               by the first match.

     Cost: P-Free for personal use, F-Freeware, S-Shareware, C-Commercial,
           X-Crippleware, D-Demoware, G-Free w/ Source


     Old info from: 01/27/92
     ---------------------------------------------------------------------

                             MS-DOS Systems
                             --------------

     BBS Software            NodeList Utilities      Other Utilities
     Name         Version    Name         Version    Name         Version
     --------------------    --------------------    --------------------
     Kitten          1.01    EditNL          4.00    MailBase       4.11a@
     Lynx            1.30    FDND            1.10    MSG              4.5*
     Merlin         1.39n    MakeNL          2.31    MsgLnk          1.0c
     Oracomm       5.M.6P@   Parselst        1.33    MsgMstr        2.03a
     Oracomm Plus     6.E@   Prune           1.40    MsgNum         4.16d
     PCBoard        14.5a    SysNL           3.14    MSGTOSS          1.3
     Phoenix         1.07*   XlatList        2.90    Netsex         2.00b
     ProBoard        1.20*   XlaxNode/Diff   2.53    OFFLINE         1.35
     QuickBBS        2.75                            Oliver          1.0a
     RBBS           17.3b    Other Utilities         OSIRIS CBIS     3.02
     RemoteAccess    1.11*   Name         Version    PKInsert        7.10
     SimplexBBS      1.05    --------------------    PolyXarc        2.1a
     SLBBS          2.15C*   2DAPoint        1.50*   QM             1.00a
     Socrates        1.11    4Dog/4DMatrix   1.18    QSort           4.04
     SuperBBS        1.12*   ARCAsim         2.31    RAD Plus        2.11
     FIDONEWS 13-45               Page 55                   4 Nov 1996


     SuperComm       0.99    ARCmail         3.00*   Raid            1.00
     TAG             2.5g    Areafix         1.20    RBBSMail        18.0
     TBBS             2.1    ConfMail        4.00    ScanToss        1.28
     TComm/TCommNet   3.4    Crossnet         1.5    ScMail          1.00
     Telegard         2.7*   DOMAIN          1.42    ScEdit          1.12
     TPBoard          6.1    DEMM            1.06    Sirius          1.0x
     WildCat!        3.02*   DGMM            1.06    SLMail         2.15C
     XBBS            1.77    DOMAIN          1.42    StarLink        1.01
                             EEngine         0.32    TagMail         2.41
     Network Mailers         EMM             2.11*   TCOMMail         2.2
     Name         Version    EZPoint          2.1    Telemail         1.5*
     --------------------    FGroup          1.00    TGroup          1.13
     BinkleyTerm     2.50    FidoPCB         1.0s@   TIRES           3.11
     D'Bridge        1.30    FNPGate         2.70    TMail           1.21
     Dreamer         1.06    GateWorks      3.06e    TosScan         1.00
     Dutchie        2.90c    GMail           2.05    UFGATE          1.03
     Milqtoast       1.00    GMD             3.10    VPurge         4.09e
     PreNM           1.48    GMM             1.21    WEdit            2.0@
     SEAdog          4.60    GoldEd         2.31p    WildMail        2.00
     SEAmail         1.01    GROUP           2.23    WMail            2.2
     TIMS       1.0(mod8)    GUS             1.40    WNode            2.1
                             Harvey's Robot  4.10    XRS             4.99
     Compression             HeadEdit        1.18    XST             2.3e
     Utilities               HLIST           1.09    YUPPIE!         2.00
     Name         Version    ISIS            5.12@   ZmailH          1.25
     --------------------    Lola           1.01d    ZSX             2.40
     ARC             7.12    Mosaic         1.00b
     ARJ             2.20
     LHA             2.13
     PAK             2.51
     PKPak           3.61
     PKZip           1.10


                             OS/2 Systems
                             ------------

     BBS Software            Other Utilities(A-M     Other Utilities(N-Z)
     Name         Version    Name         Version    Name         Version
     --------------------    --------------------    --------------------
     Kitten          1.01    ARC             7.12    oMMM            1.52
     SimplexBBS   1.04.02+   ARC2            6.01    Omail            3.1
                             ConfMail        4.00    Parselst        1.33
                             EchoStat         6.0    PKZip           1.02
     Network Mailers         EZPoint          2.1    PMSnoop         1.30
     Name         Version    FGroup          1.00    PolyXOS2        2.1a
     --------------------    GROUP           2.23    QSort            2.1
     BinkleyTerm     2.50    LH2             2.11    Raid             1.0
     BinkleyTerm(S)  2.50    MSG              4.2    Remapper         1.2
     BinkleyTerm/2-MT        MsgLink         1.0c    Tick             2.0
                  1.40.02    MsgNum         4.16d    VPurge         4.09e
     SEAmail         1.01


                             Xenix/Unix 386
                             --------------
     FIDONEWS 13-45               Page 56                   4 Nov 1996


     BBS Software            Network Mailers         Other Utilities
     Name         Version    Name         Version    Name         Version
     --------------------    --------------------    --------------------
                                                     ARC             5.21
                                                     C-LHARC         1.00
      |Contact:  Willy Paine 1:343/15,|              MSGLINK         1.01
      |or Eddy van Loo 2:285/406      |              oMMM            1.42
                                                     Omail           1.00
                                                     ParseLst        1.32
                                                     Unzip           3.10
                                                     VPurge          4.08
                                                     Zoo             2.01


                             Macintosh
                             ---------

     BBS Software            Network Mailers         Other Software
     Name         Version    Name         Version    Name         Version
     --------------------    --------------------    --------------------
     FBBS            0.91    Copernicus       1.0    ArcMac           1.3
     Hermes         1.6.1    Tabby            2.2    AreaFix          1.6
     Mansion         7.15                            Compact Pro     1.30
     Precision Sys. 0.95b                            EventMeister     1.0
     Red Ryder Host   2.1                            Export          3.21
     Telefinder Host                                 Import           3.2
                  2.12T10                            LHARC           0.41
                                                     MacArd          0.04
                                                     Mantissa        3.21
     Point System                                    Mehitable        2.0
     Software                                        OriginatorII     2.0
     Name         Version                            PreStamp         3.2
     --------------------                            StuffIt Classic  1.6
     Copernicus      1.00                            SunDial          3.2
     CounterPoint    1.09                            TExport         1.92
     MacWoof          1.1                            TimeStamp        1.6
                                                     TImport         1.92
                                                     Tset             1.3
                                                     TSort            1.0
                                                     UNZIP          1.02c
                                                     Zenith           1.5
                                                     Zip Extract     0.10


                             Amiga
                             -----

     BBS Software            Network Mailers         Other Software
     Name         Version    Name         Version    Name         Version
     --------------------    --------------------    --------------------
     4D-BBS          1.65    BinkleyTerm     1.00    Areafix         1.48
     DLG Pro.       0.96b    TrapDoor        1.80    AReceipt         1.5
     Falcon CBCS     1.00    WelMat          0.44    ChameleonEdit   0.11
     Starnet         1.0q@                           ConfMail        1.12
     TransAmiga      1.07                            ElectricHerald  1.66
     XenoLink         1.0    Compression             FFRS             1.0@
     FIDONEWS 13-45               Page 57                   4 Nov 1996


                             Utilities               FileMgr         2.08
                             Name         Version    Fozzle           1.0@
     NodeList Utilities      --------------------    Login           0.18
     Name         Version    AmigArc         0.23    MessageFilter   1.52
     --------------------    booz            1.01    Message View    1.12
     ParseLst        1.66    LHARC           1.30    oMMM            1.50
     Skyparse        2.30    LhA             1.10    PolyXAmy        2.02
     TrapList        1.40    LZ              1.92    RMB             1.30
                             PkAX            1.00    Roof           46.15
                             UnZip            4.1    RoboWriter      1.02
                             Zippy (Unzip)   1.25    Rsh            4.07a
                             Zoo             2.01    Tick            0.75
                                                     TrapToss        1.20
     |Contact: Maximilian Hantsch 2:310/6|           Yuck!           2.02


                             Atari ST/TT
                             -----------

     BBS Software            Network Mailers         Other Utilities
     Name         Version    Name         Version    Name         Version
     --------------------    --------------------    --------------------
     FIDOdoor/ST    2.5.1    BinkleyTerm   2.40n9    ApplyList       1.00@
     FiFo            2.1v    The Box         1.95*   Burep            1.1
     LED ST          1.00                            ComScan         1.04
     QuickBBS/ST     1.06*                           ConfMail        4.10
                             NodeList  Utilities     Echoscan        1.10
                             Name         Version    FDrenum        2.5.2
     Compression             --------------------    FastPack        1.20
     Utilities               ParseList       1.30    Import          1.14
     Name         Version    EchoFix         1.20    oMMM            1.40
     --------------------    sTICK/Hatch     5.50    Pack            1.00
     ARC             6.02                            Trenum          0.10
     LHARC          2.01i
     PackConvert
     STZip            1.1*
     UnJARST         2.00
     WhatArc         2.02


                             Tandy Color Computer 3 (OS-9 Level II)
                             --------------------------------------

     BBS Software            Compression Utility     Other Utilities
     Name         Version    Name         Version    Name         Version
     --------------------    --------------------    --------------------
     RiBBS           2.02+   Ar               1.3    Ascan            1.2
                             DeArc           5.12    AutoFRL          2.0
                             OS9Arc           1.0    Bundle           2.2
                             UnZip           3.10    CKARC            1.1
                             UnLZH            3.0    EchoCheck       1.01
                                                     FReq            2.5a
                                                     LookNode        2.00
                                                     ParseLST
                                                     PReq             2.2
                                                     RList           1.03
     FIDONEWS 13-45               Page 58                   4 Nov 1996


                                                     RTick           2.00
                                                     UnBundle         1.4
                                                     UnSeen           1.1

     --  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --
     Key to old info:
           + - Netmail Capable (Doesn't Require Additional Mailer Software)
           * - Recently Updated Version
           @ - New Addition
     --  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --

     Please send updates and suggestions to: Peter Popovich, 1:363/264

     -----------------------------------------------------------------

     FIDONEWS 13-45               Page 59                   4 Nov 1996


     =================================================================
                            FIDONEWS PUBLIC-KEY
     =================================================================


     [this must be copied out to a file starting at column 1 or
      it won't process under PGP as a valid public-key]


     -----BEGIN PGP PUBLIC KEY BLOCK-----
     Version: 2.6.2
     Comment: Clear-signing is Electronic Digital Authenticity!

     -----END PGP PUBLIC KEY BLOCK-----


     Pending a formal decision about including 'encrypted' material inside
     FidoNews from the Zone Coordinator Council, the guts of the FidoNews
     public-key have been removed from this listing.

     File-request FNEWSKEY from 1:1/23 [1:18/14] or download it from the
     Rights On! BBS at 1-904-409-7040 anytime except 0100-0130 ET and Zone
     1 ZMH at 1200-9600+ HST/V32B.

     This section will contain only this disclaimer and instructions until
     a ZCC decision is forwarded to the Editor.

     Sorry for any inconvenience.

     -----------------------------------------------------------------

     FIDONEWS 13-45               Page 60                   4 Nov 1996


     =================================================================
                           FIDONEWS INFORMATION
     =================================================================

     ------- FIDONEWS MASTHEAD AND CONTACT INFORMATION -------

     Editor: Christopher Baker

     Editors Emeritii: Thom Henderson, Dale Lovell,
                       Vince Perriello, Tim Pozar,
                       Tom Jennings, Sylvia Maxwell,
                       Donald Tees

     "FidoNews Editor"
         FidoNet  1:1/23
         BBS  1-904-409-7040,  300/1200/2400/14400/V.32bis/HST(ds)

      more addresses:
         Christopher Baker -- 1:18/14, [e-mail]
                                       [e-mail]

     (Postal Service mailing address)
         FidoNews Editor
         P.O. Box 471
         Edgewater, FL 32132-0471
         U.S.A.


     voice:  1-904-409-3040 [1400-2100 ET only, please]
                            [1800-0100 UTC/GMT]

     ------------------------------------------------------

     FidoNews is published weekly by and for the members of the FIDONET
     INTERNATIONAL AMATEUR ELECTRONIC MAIL system.  It is a compilation
     of individual articles contributed by their authors or their
     authorized agents.  The contribution of articles to this compilation
     does not diminish the rights of the authors.  OPINIONS EXPRESSED in
     these articles ARE THOSE OF THE AUTHORS and not necessarily those of
     FidoNews.

     Authors retain copyright on individual works; otherwise FidoNews is
     Copyright 1996 Christopher Baker.  All rights reserved.  Duplication
     and/or distribution permitted for noncommercial purposes only.  For
     use in other circumstances, please contact the original authors, or
     the Editor.

                            =*=*=*=*=*=*=*=*=

     OBTAINING COPIES: The most recent issue of FidoNews in electronic
     form may be obtained from the FidoNews Editor via manual download or
     file-request, or from various sites in the FidoNet and Internet.
     PRINTED COPIES may be obtained by sending SASE to the above postal
     address.  File-request FIDONEWS for the current Issue.  File-request
     FNEWS for the current month in one archive.  Or file-request specific
     back Issue filenames in distribution format [FNEWSDnn.LZH] for a
     FIDONEWS 13-45               Page 61                   4 Nov 1996


     particular Issue.  Monthly Volumes are available as FNWSmmmy.ZIP
     where mmm = three letter month [JAN - DEC] and y = last digit of the
     current year [6], i.e., FNWSMAY6.ZIP for all the Issues from May 96.

     Annual volumes are available as FNEWSn.ZIP where n = the Volume number
     1 - 12 for 1984 - 1995, respectively. Annual Volume archives range in
     size from 48K to 1.2M.


     INTERNET USERS: FidoNews is available via:

                          http://www.fidonet.org/fidonews.htm
                          ftp://ftp.fidonet.org/pub/fidonet/fidonews/
                          ftp://ftp.aminet.org/pub/aminet/comm/fido/

     You can read the current FidoNews Issue in HTML format at:

                          http://www.geocities.com/athens/6894/

     STAR SOURCE for ALL Past Issues via FTP and file-request -
     Available for FReq from 1:396/1 or by anonymous FTP from:

                          ftp://ftp.sstar.com/fidonet/fnews/

     Each yearly archive also contains a listing of the Table-of-Contents
     for that year's issues.  The total set is currently about 11 Megs.

                                 =*=*=*=

     The current week's FidoNews and the FidoNews public-key are now also
     available almost immediately after publication on the Editor's new
     homepage on the World Wide Web at:

                  http://ddi.digital.net/~cbaker84/fidonews.html

     There are also links there to jim barchuk's HTML FidoNews source and
     to John Souvestre's FTP site for the archives. There is also an email
     link for sending in an article as message text. Drop on over.

                            =*=*=*=*=*=*=*=*=

     A PGP generated public-key is available for the FidoNews Editor from
     1:1/23 [1:18/14] by file-request for FNEWSKEY or by download from
     Rights On! BBS at 1-904-409-7040 as FIDONEWS.ASC in File Area 18.  It
     is also posted twice a month into the PKEY_DROP Echo available on the
     Zone 1 Echomail Backbone.

                                *=*=*=*=*

     Anyone interested in getting a copy of the INTERNET GATEWAY FAQ may
     file-request GISFAQ.ZIP from 1:133/411.0, or send an internet message
     to [e-mail].  No message or text or subject is
     necessary.  The address is a keyword that will trigger the automated
     response.  People wishing to send inquiries directly to David Deitch
     should now mail to [e-mail] rather than the
     previously listed address.
     FIDONEWS 13-45               Page 62                   4 Nov 1996


                                *=*=*=*=*

     SUBMISSIONS: You are encouraged to submit articles for publication in
     FidoNews. Article submission requirements are contained in the file
     ARTSPEC.DOC, available from the FidoNews Editor, or file-requestable
     from 1:1/23 [1:18/14] as file "ARTSPEC.DOC".  ALL Zone Coordinators
     also have copies of ARTSPEC.DOC. Please read it.

     "Fido", "FidoNet" and the dog-with-diskette are U.S. registered
     trademarks of Tom Jennings, P.O. Box 410923, San Francisco, CA 94141,
     and are used with permission.

             "Disagreement is actually necessary,
              or we'd all have to get in fights
              or something to amuse ourselves
              and create the requisite chaos."
                                -Tom Jennings

      -30-


     -----------------------------------------------------------------